HTTP接口安全机制之参数签名

在上一篇的
HTTP接口安全机制之用户认证
的内容中,解决了身份认证和用户名密码安全传输的问题.

用户名和密码没有泄露，用户在系统中进行各项操作就一定安全了吗？

不一定，因为其没有防止参数被修改和拦截重放，也没有限制请求来源。
例子：xx 网站的支付接口
http://www.example.com/sell/detail?buyquantity=1&subtotal=0
一旦该请求被拦截，不法分子可能会修改其中的购买数量或支付总金额。那么，如何防止参数被修改？

1）对参数内容进行加密传输—让不法分子看不到参数及其值的明文
2）参数签名—允许不法分子修改参数，但是修改后无效

接下来，主要给大家讲解一下参数签名：
了解参数签名之前，先了解一下数字签名。

数字签名的过程：

消息原文+hash --原文摘要 + 私钥加密 ----数字签名
发送端： 消息原文 + 数字签名
接收端： 消息原文 + hash --预期原文摘要
收到的数字签名–公钥解密 —实际原文摘要
验证：比较两个摘要，如果消息原文没有被修改，并且是正确的发送者（合法请求来源）发送的消息，则两个摘要相等，否则不相等。

参数签名
接口安全中的数字签名：
例子：http:// www.example.com/sell/detail?buyquantity=1&subtotal=0
消息原文：buyquantity=1&subtotal=0
私钥和公钥：需要调用者像服务端申请appkey=woniusales1.3 appsecrect= woniusales1.3123(自己知道)
生成签名过程：

1）对传参进行排序，按参数名称进行排序（升序、降序、其他顺序） 按升序：buyquantity=1&subtotal=0
2）去掉其中的&符号：buyquantity=1subtotal=0
3）在2）中串进行hash运算
----md5签名：sign=2619f3d60e253ec6d63dd77d9c266e93
4) 将签名参数附加在原始请求后面，发送请求 http://www.example.com/sell/detail?buyquantity=1&subtotal=0?sign=2619f3d60e253ec6d63dd77d9c266e93

接收端验证签名：

1）接收到请求
http://www.example.com/sell/detail?buyquantity=1&subtotal=0?sign=2619f3d60e253ec6d63dd77d9c266e93
2)查看是否有签名参数，有则继续3)，无则证明本次请求无效，不予以处理
3)服务器端按照与客户端协商好的签名规则对收到的参数（除去sign）进行同样的运算 Sign_new =2619f3d60e253ec6d63dd77d9c266e93
4)比较两个签名 Sign == Sign_new ？
如果相等，说明参数合法，服务器可以继续处理 如果不相等，说明参数被修改过，服务器不予以处理

这里只能验证参数是否被修改，无法验证请求来源是否合法，如果需要验证请求来源的合法性，需要加上调用者的私钥，后续生成签名流程与前面一致（更严谨一点，可以将签名的hash算法换成某种加密算法，而这里的appkey和appsecrect就是对应的加密秘钥和解密秘钥，当然发送方要负责保管好自己的私钥）：
http://www.example.com/sell/detail?buyquantity=1&subtotal=0&appkey=woniusales1.3

服务器收到请求需要先验证有没有sign参数和appkey参数，然后验证appkey参数是否是已分配过的有效key，不是则无效，进而实现了对非法请求来源的校验。

如果要进一步防止请求被拦截重放，可以在请求参数里面加上当前请求的时间戳，而在服务器端定义一个过期时间T
http://www.example.com/sell/detail?createtime=1564567890&buyquantity=1&subtotal=0?appkey=woniusales&sign=0fd708bc44ee8da7991d24be65f0472a

服务器收到请求时出了需要校验是否有sign和appkey参数，还需要检验时间戳合法性，服务器收到请求的时间Time2 需要满足Time2 - createtime < T ，否则证明请求过期无效，服务器不予以处理。
这里的过期时间T越短越能防止请求被拦击重发，越长约能兼容网络延时。
时钟要求：通信各方的计算机时钟保持同步。

最后，安全是相对的，没有绝对安全。

无论你在学习上有任何问题，重庆蜗牛学院欢迎你前来咨询，联系QQ：296799112