JWT-token—前后端分离架构的api安全问题

Posted 2023-05-05

参考技术A

前后端分离架构带来的好处一搜一大堆，我们来看一下分离后后端接口的安全问题。
前后端分离架构现状：

这样的情况后端api是暴露在外网中，因为常规的web项目无论如何前端都是要通过公网访问到后台api的，带来的隐患也有很多。
1.接口公开，谁都可以访问
2.数据请求的参数在传输过程被篡改
3.接口被重复调用
...

session和cookie都是客户端与服务端通讯需要提供的认证，当客户端的值和服务器的值吻合时，才允许请求api，解决了第1个问题，但是当攻击者获取到了传输过程中的session或者cookie值后，就可以进行第2、3种攻击了

JWT标准的token包含三部分：

头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Header

Payload也是一个JSON对象。包含了一些其他的信息

这里面的前五个字段都是由JWT的标准所定义的。

将上面的JSON对象进行 [base64编码] 可以得到下面的字符串。这个字符串我们将它称作JWT的Payload

将上面的两个编码后的字符串都用句号 . 连接在一起（头部在前），就形成了

最后，我们将上面拼接完的字符串用 HS256算法 进行加密。在加密的时候，我们还需要提供一个 密钥（secret） 。如果我们用 mystar 作为密钥的话，那么就可以得到我们加密后的内容

这一部分叫做 签名

最后将这一部分签名也拼接在被签名的字符串后面，我们就得到了完整的JWT

签名解决了数据传输过程中参数被篡改的风险
一般而言，加密算法对于不同的输入产生的输出总是不一样的，如果有人 对Header以及Payload的内容解码之后进行修改，再进行编码的话，那么新的头部和载荷的签名和之前的签名就将是不一样的。 而且，如果不知道服务器加密的时候用的密钥的话，得出来的签名也一定会是不一样的。

解决了篡改数据的问题，还有第3个问题，那就是攻击者不修改数据，只是重复攻击

比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道， 因为JWT机制是无状态的。

可以在Payload里增加时间戳并且前后端都参与来解决：

前后端分离微服务架构如何设计

参考技术A

前端

前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。

比如：

一般前端工作包括六个部分：

后端

如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。

一般后端工作包括五个部分：

1、与产品经理对接需求

2、业务 API 接口开发：根据根据需求文档进行业务接口开发

4、接口对接：与前端开发人员接口对接

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

前端开发技术栈

h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等

后端开发技术栈

SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、数据库、缓存框架（ Redis ， Codis , Memcached 等），大数据框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等

技术选型

最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。

数据格式

后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用 REST 风格以 JSON 格式提供数据。

接口设计

一个接口设计的好坏，直接影响到前后端的一些沟通协调问题。

依笔者的经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。

接口容量问题

一个接口的业务容量大小，往往代表前后端工作量的大小。

如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口 Ajax 异步处理；

如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。

一、前后端分离的思想要转变

不能老是按照传统WEB（ js/h5/css/ 后端代码放在一个工程）开发思维去看待前后端分离

二、沟通成本问题

以前传统 WEB 开发，开发人员从需求到设计到开发基本上是一个人。

而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。

三、组织结构问题

康威定律

第一定律： Communication dictates design （组织沟通方式会通过系统设计表达出来）

第二定律： There is never enough time to do something right, but there is always enough time to do it over （时间再多一件事情也不可能做得美，但总有时间做完一件事情）

第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （线型系统和线型组织架构间有潜在的异质同态特性）

第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems （大的系统组织总是比小系统更倾向于分解）

康威定律说明以下几点

四、部署及监控运维

前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。

总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做得比较好的