API接口安全

目前项目都是前后端分离或者有对外提供接口的需求，在这些情况下，就要考虑接口安全。

如果不重视接口安全，可能导致严重的危害，例如数据盗取，服务宕机等。

可能的安全问题:

        1.明文密码被攻击者抓包看到

                前端可对密码或者一些关键信息进行加密传输.

        2.登录成功后，后端返回的是userId

                用户登录后，后端可以返回token不要直接返回userId，并且在后端建立userId与token的对应关系，每次发送请求都依据token来找到对应关系，对token设置有效时间并且不直接暴露userId，这样可以起到辅助安全的作用。

        3.攻击者直接拿我们加密后的密码或者token去做操作

                前端可以将请求的密码或token与时间戳进行混合后，再加密。这样即使被拦截，攻击者不知道我们的密码或token是什么。同理，后端也可以对响应的关键数据进行加密后，再返回给前端。别人获得响应后，也不知道我们的具体信息是什么。

        4.攻击者拦截数据后，肆意修改，增加后端解密的难度或者访问一些重要的数据

                可以通过签名（验签）的方式，与后端约定规则。每次请求都携带签名字段，如果为了完全安全，可以对整个请求体进行加密后（对称加密，可解密），再进行签名。

        验签的规则：

                简单版本：对请求的数据进行ASCII排序，参数的值为空不参与签名，区分大小写，传送的sign不参与签名，拼接密钥，得到最终需要MD5加密的字符串。

                复杂版本：简单版本仍然不是安全的，如果攻击者监听并截取到了请求片段，然后把签名单独截取出来模仿正式请求方欺骗服务器进行重复请求（重放攻击）仍然有安全问题。我们可以增加时效性，来避免此类攻击。

        加入 timestamp + nonce 两个参数来控制请求有效性，防止重放攻击。   

  timestamp                             

        请求端：timestamp由请求方生成，代表请求被发送的时间（需双方共用一套时间计数系统）随请求参数一并发出，并将 timestamp作为一个参数加入 sign 加密计算。

        服务端：平台服务器接到请求后对比当前时间戳，设定不超过60s 即认为该请求正常，否则认为超时并不反馈结果（由于实际传输时间差的存在所以不可能无限缩小超时时间）。 但是这样仍然是仅仅不够的，仿冒者仍然有60秒的时间来模仿请求进行重放攻击。所以更进一步地，可以为sign 加上一个随机码（称之为盐值）这里我们定义为 nonce。

        nonce

        请求端：nonce 是由请求方生成的随机数（在规定的时间内保证有充足的随机数产生，即在60s 内产生的随机数重复的概率为0）也作为参数之一加入 sign 签名。

        服务端：服务器接受到请求先判定 nonce 是否被请求过(一般会放到redis中)，如果发现 nonce 参数在规定时间是全新的则正常返回结果，反之，则判定是重放攻击。而由于以上2个参数也写入了签名当中，攻击方刻意增加或伪造 timestamp 和 nonce 企图逃过重放判定都会导致签名不通过而失败。

        5.攻击者知道网页代码或者反编译后端代码，自己依据规则生成签名

        可以对前端或后端代码进行混淆（前端jshsman，后端Proguard，只是举例，工具很多）。

        6.其它的安全措施

        A.黑白名单 对请求接口的ip进行过滤

        B.限流 当遇到攻击时，能通过修改配置或者实时对攻击者进行限流，以免发生雪崩的情况。

        C.https 就是http+SSL，在http的基础上添加一套SSL协议，专门用来保证http安全
SSL也是使用加密，解密，签名，校验等方式来对保证安全的，只不过它是一套专门的安全协议，有着标准完善的规范.一般一年价格几百到几万不等。

备注：并不是所有的接口都需要做到完全安全，因为安全级别越高，意味着编码复杂度越高，也会影响到服务器的性能。一般只对关键环节才使用多种安全方案，其它地方使用一种方案即可

参考文章：

(66条消息) 【Java】【通信安全】怎么保证http请求的安全性_命运之手的博客-CSDN博客_怎么保证http请求数据安全

https://juejin.cn/post/6983864029550739463