![d7c21b6c80d102c01146e221fd420aa6.png](https://i-blog.csdnimg.cn/blog_migrate/3a52d58205d6d6c0610c58c5bddcafcc.jpeg)
前言
前后端分离的开发方式,我们以接口为标准来进行推动,定义好接口,各自开发自己的功能,最后进行联调整合。无论是开发原生的APP还是webapp还是PC端的软件,只要是前后端分离的模式,就避免不了调用后端提供的接口来进行业务交互。
网页或者app,只要抓下包就可以清楚的知道这个请求获取到的数据,也可以伪造请求去获取或攻击服务器;也对爬虫工程师来说是一种福音,要抓你的数据简直轻而易举。那我们怎么去解决这些问题呢?
接口签名
我们先考虑一下接口数据被伪造,以及接口被重复调用的问题,要解决这个问题我们就要用到接口签名的方案,
签名流程
![7b30e8497c54e3a0c7597700396e7cbf.png](https://i-blog.csdnimg.cn/blog_migrate/cab89cae95cec81c1f2e7a5b82762a30.jpeg)
签名规则
1、线下分配appid和appsecret,针对不同的调用方分配不同的appid和appsecret
2、加入timestamp(时间戳),5分钟内数据有效
3、加入临时流水号 nonce(防止重复提交),至少为10位。针对查询接口,流水号只用于日志落地,便于后期日志核查。针对办理类接口需校验流水号在有效期内的唯一性,以避免重复请求。
4、加入签名字段signature,所有数据的签名信息。
以上字段放在请求头中。
签名的生成
签名signature字段生成规则
所有动态参数 = 请求头部分 + 请求URL地址 + 请求Request参数 + 请求Body
上面的动态参数以key-value的格式存储,并以key值正序排序,进行拼接
最后拼接的字符串 在拼接appSecret
signature = DigestUtils.md5DigestAsHex(sortParamsMap + appSecret)
即拼接成一个字符串,然后做md5不可逆加密
请求头部分
请求头=“appId=xxxx&nonce=xxxx×temp=xxxx&sign=xxx”
请求头中的4个参数是必须要传的,否则直接报异常
请求URL地址
这个就是请求接口的地址包含协议,如
https://mso.xxxx.com.cn/api/user
请求Request参数
即请求为Get方式的时候,获取的传入的参数
请求Body
即请求为Post时,请求体Body
从request inputstream中获取保存为String形式
签名算法实现
基本原理其实也比较简单,就是自定义filter,对每个请求进行处理;整体流程如下
1)验证必须的头部参数
2)获取头部参数,request参数,Url请求路径,请求体Body,把这些值放入SortMap中进行排序
3)对SortMap里面的值进行拼接
4)对拼接的值进行加密,生成sign
5)把生成的sign和前端传入的sign进行比较,如果不相同就返回错误
我们来看一下代码
![25e092ef6e13331e2ad275f85146a3a1.png](https://i-blog.csdnimg.cn/blog_migrate/c6b059b239bac62c037d4e324ec1dd42.png)
![1152f46c7cb6c4abb62b7e4c70f87fae.png](https://i-blog.csdnimg.cn/blog_migrate/3f81bb146fa8b7054dfb55cc321ac371.jpeg)
以上是filter类,其中有个appSecret需要自己业务去获取,它的作用主要是区分不同客户端app。并且利用获取到的appSecret参与到sign签名,保证了客户端的请求签名是由我们后台控制的,我们可以为不同的客户端颁发不同的appSecret。
我们再来看看验证头部参数
![164af290fc1fff064f5e975d2d9c9dc3.png](https://i-blog.csdnimg.cn/blog_migrate/f4313a6170b1458caf82dd0bd3e2aab0.jpeg)
image
上图其实就是验证是否传入值;不过其实有个很重要的一点,就是对此请求进行时间验证,如果大于10分钟表示此链接已经超时,防止别人来到这个链接去请求。这个就是防止盗链。
我们在来看看,如何获取各个参数
![24e8ce4305c471f73f0e9ee7cdd173e4.png](https://i-blog.csdnimg.cn/blog_migrate/a0c5484512bf8f5ab5cc2211131bd287.jpeg)
![22ab779cba55ce6b8426a2d22a7cdcad.png](https://i-blog.csdnimg.cn/blog_migrate/62598ca00e663f0db0f45a0b26264356.jpeg)
上面我们获取了各个参数,相对比较简单;我们在来看看生成sign,和验证sign
![ee1bd938191ac2d826ffc7e2600b3bc2.png](https://i-blog.csdnimg.cn/blog_migrate/1454ab170ee6dac252f3810521eaf0de.jpeg)
上面的流程中,会有个额外的安全处理,
· 防止盗链,我们可以让链接有失效时间
· 利用nonce参数,防止重复提交
在签名验证成功后,判断是否重复提交;
原理就是结合redis,判断是否已经提交过
![c251fe7669a779d161da870377c8a8a8.png](https://i-blog.csdnimg.cn/blog_migrate/cc96cc61a0e641f8b3f7480e360223c7.jpeg)
总结
今天我们用签名的方式,对我们对外提供的接口起到了保护作用;但这种保护仅仅做到了防止别人篡改请求,或者模拟请求。
但是还是缺少对数据自身的安全保护,即请求的参数和返回的数据都是有可能被别人拦截获取的,而这些数据又是明文的,所以只要被拦截,就能获得相应的业务数据。
以上来自头条:作者:享学课堂|侵删
原文链接:https://www.toutiao.com/a6865544118026797579/
补充
另外,使用TOKEN+签名认证 保证请求安全性 。这个也是面试官经常问到的原理,这里我补充一下:
token+签名认证的主要原理是:
1.做一个认证服务,提供一个认证的webapi,用户先访问它获取对应的token
2.用户拿着相应的token以及请求的参数和服务器端提供的签名算法计算出签名后再去访问指定的api
3.服务器端每次接收到请求就获取对应用户的token和请求参数,服务器端再次计算签名和客户端签名做对比,如果验证通过则正常访问相应的api,验证失败则返回具体的失败信息
总结方案:
1、参数加密: 客户端和服务端参数采用RSA加密后传递,原则上只有持有私钥的服务端才能解密客户端公钥加密的参数,避免了参数篡改的问
2、请求签名:采用一套签名算法,对请求进行签名验证,保证请求的唯一性