Flask接口签名sign原理与实例代码浅析

觉得废话多的话，可以直接看代码

作用

防止有人不停的刷接口，对接口作限制

比如说，登录接口，按道理说，应该只有app会请求这个接口

但是，如果有人抓取app的请求，就会得到登录接口的地址和请求参数

如果他写了个脚本，不断的访问登录接口，去测登录名密码，那么有些有些用户的密码策略过于简单，是很容易被试出来的

所以，接口签名就是专门用来限制这个的，只有app(自己人)才能通过校验

原理

1.服务器和app，各自存储一个相同的秘钥

2.app请求时，把传的参数用秘钥进行加密，生成一个sign签名，一同传递过去

3.服务器接到请求后，也会对传递的参数进行加密，也生成一个sign签名，拿服务器生成的sign和接口请求的sing比对一下，如果相同，那么就可以证明，是自己人请求的，就予以放行

因为这个秘钥，只有自己人才会有，同样的秘钥生成的sign签名，肯定是一模一样的

这个秘钥，一般是开发的时候，线下给到app开发，集成编译到app里面的

问题

举例，app和服务器，各自保存了一个秘钥，进行签名验证

1.app请求登录接口，账号名为abcd，密码为123456，

2.app对账户名和密码用秘钥加密生成签名，去请求登录接口

3.服务器收到请求，对账号名和密码也用秘钥加密生成签名，对比发现签名一致，然后予以通过

4.请求成功

问题1

但是，如果下次app还去请求登录的时候，生成的签名，是不是还是一模一样？

因为都是对账号和密码加密生成签名，那么只要账号和密码不变，那么生成的签名肯定是一模一样的

那如果坏人直接抓包拿到签名、账号和密码，是不是他也可以仿造登录请求，要知道，服务器只接受请求，他是分辨不出来的

所以，即使是相同的账号和密码，也要保证，每次的签名都不一致

解决办法

在对账号和密码进行加密的时候，生成当前时间的时间戳，一起加密，这样就保证了每次生成的签名都一样了

传递参数的时候，也需要把加密用的时间戳一同传递过去，因为请求时候延迟的，服务器并不知道你是哪个时间进行加密的

那么现在生成签名和请求的步骤就是：

1.app先对账号、密码、时间戳，用秘钥进行加密得到签名

2.app请求登录接口，传参：账号、密码、时间戳、签名

问题2

那么问题又来了，跟刚才的问题一样，如果有人抓包，得到账号、密码、时间戳、签名，然后去伪造请求，是不是服务器还会通过？

只要账号、密码、时间戳不变化，那么生成的签名，还是一模一样的。

解决办法

服务器对时间戳进行校验，与当前时间不能相差10秒

这样就保证了，这个签名的有效期只有10秒，过了10秒后，就失效了

如果想要新的签名，那么就需要用新的时间戳了

代码

如果需要传递很多参数的时候，还需要对参数进行排序后再加密，要不然app和服务器用了不一样的字符串加密，校验还是会失败的

import hashlib  
import time  
salt = 'nx24Tej@R4gWVCopJkjHWjBo@n58LdQ5'  # 盐, 加密生成签名的秘钥  
def validate_sign(sign, ts, **kwargs):  
   """时间戳有效期10秒，排序顺序为：盐+时间戳+按照字母排序的参数的值"""  
   # 首先判断ts时间戳，有没有超过10秒有效期  
   now_ts = int(time.time())  
   if now_ts - int(ts) > 10:  
       return False  
   # 对字典中的键进行排序  
   sort_dict = sorted(kwargs.items(), key=lambda x: x[0])  
   # 按照排序拿出值，拼接成字符串，然后加密生成签名  
   s = salt + str(ts)  
   for key, value in sort_dict:  
       s += str(value)  
   # 使用sha256加密，与app也要约定好加密方式  
   new_sign = hashlib.sha256(s.encode('utf-8')).hexdigest()  
   # 比对签名是否一致  
   if sign == new_sign:  
       return True  
   return False  
validate_sign(1, int(time.time()), phone="15555555555", password="123456")  
# 排序后的字符串：nx24Tej@R4gWVCopJkjHWjBo@n58LdQ5167541269212345615555555555  
# 生成的签名: d87f2833c1f6a1d0d3c67bafdeb0965b0503385dce615662229b27333c9963f7

来源：https://blog.csdn.net/w1054230914/article/details/128872847