API接口安全

ゝ一世哀愁。 2024-03-26 14:44 31阅读 0赞

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

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

**可能的安全问题:**

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请求数据安全][66_ _Java_http_-CSDN_http]

https://juejin.cn/post/6983864029550739463

[66_ _Java_http_-CSDN_http]: https://blog.csdn.net/u013718730/article/details/94440881