接口安全验证及防刷处理方案

暴露在外网的api接口需要做到防篡改和防重放才能保证接口安全。

比如：短信验证接口，支付接口，请求时长超过1S以上的

防篡改

我们知道http 是一种无状态的协议，服务端并不知道客户端发送的请求是否合法，也并不知道请求中的参数是否正确。

举个例子, 现在有个充值的接口，调用后可以给用户增加对应的余额。

http://localhost/api/user/insert?user_id=1001&amount=10

如果非法用户通过抓包获取到接口参数后，修改user_id 或 amount的值就可以实现给任意账户添加余额的目的。

如何解决

采用https协议可以将传输的明文进行加密，但是黑客仍然可以截获传输的数据包，进一步伪造请求进行重放攻击。如果黑客使用特殊手段让请求方设备使用了伪造的证书进行通信，那么https加密的内容也会被解密。

一般的做法有2种：

1. 采用https方式把接口的数据进行加密传输，即便是被黑客破解，黑客也花费大量的时间和精力去破解。

2. 接口后台对接口的请求参数进行验证，防止被黑客篡改；

• 步骤1：客户端使用约定好的秘钥对传输的参数进行加密，得到签名值sign1，并且将签名值也放入请求的参数中，发送请求给服务端

• 步骤2：服务端接收到客户端的请求，然后使用约定好的秘钥对请求的参数再次进行签名，得到签名值sign2。

• 步骤3：服务端比对sign1和sign2的值，如果不一致，就认定为被篡改，非法请求。

防重放

防重放也叫防复用。简单来说就是我获取到这个请求的信息之后什么也不改,，直接拿着接口的参数 重复请求这个充值的接口。此时我的请求是合法的, 因为所有参数都是跟合法请求一模一样的。

重放攻击会造成两种后果：

1. 针对插入数据库接口：重放攻击，会出现大量重复数据，甚至垃圾数据会把数据库撑爆。

2. 针对查询的接口：黑客一般是重点攻击慢查询接口，例如一个慢查询接口1s，只要黑客发起重放攻击，就必然造成系统被拖垮，数据库查询被阻塞死。

对于重放攻击一般有两种做法：

基于timestamp（时间戳）的方案

每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。因为一次正常的HTTP请求，从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间比较，是否超过了60s，如果超过了则认为是非法请求。

一般情况下，黑客从抓包重放请求耗时远远超过了60s，所以此时请求中的timestamp参数已经失效了。如果黑客修改timestamp参数为当前的时间戳，则sign1参数对应的数字签名就会失效，因为黑客不知道签名秘钥，没有办法生成新的数字签名。

但是这种方式的漏洞也是显而易见，如果在60s之内进行重放攻击，那就没办法了，所以这种方式不能保证请求仅一次有效。

老鸟们一般会采取下面这种方案，既可以解决接口重放问题，又可以解决接口一次请求有效的问题。

基于nonce + timestamp 的方案

nonce的意思是仅一次有效的随机字符串，要求每次请求时该参数要保证不同。

实际使用用户信息+时间戳+随机数等信息做个哈希之后，作为nonce参数。

此时服务端的处理流程如下：

1. 去 redis 中查找是否有 key 为 nonce:{nonce}的 string

2. 如果没有，则创建这个 key，把这个 key 失效的时间和验证 timestamp 失效的时间一致，比如是 60s。

3. 如果有，说明这个 key 在 60s 内已经被使用了，那么这个请求就可以判断为重放请求。

这种方案nonce和timestamp参数都作为签名的一部分传到后端，基于timestamp方案可以让黑客只能在60s内进行重放攻击，加上nonce随机数以后可以保证接口只能被调用一次，可以很好的解决重放攻击问题。