故事的开始,面试官问了我一个问题:前端
如何防止http请求中数据被篡改?nginx
回答:面试
1.1.客户端全部请求,请求到代理服务器(nginx),代理服务器维护黑/白名单的ip,决定是否转发请求。缓存
1.2.项目建立一个filter,拦截全部请求,在filter的方法中,经过request信息匹配ip黑/白名单,和url的拦截规则,决定是否合法。服务器
优势:简单粗暴。并发
缺点:须要客户端的IP固定。性能
应用场景:并发量小的场景。好比系统的后台管理服务,客服须要人工审批和经过涉及到钱财的业务,就可使用这种简单粗暴的方式,防止帐号泄露,接口泄露等等。ui
2.1前端发起http请求,对参数排序,而后使用 参数与私钥拼接,在进行md5加密 等方式,生成一个签名出来,一块儿发给服务端,服务端这边获取到参数,签名,再使用本身的私钥进行一样方式的加密生成签名,比对签名是否一致。一致则认为合法,不一致则不合法。可是没法防止重复请求攻击!加密
2.2针对上面方法升级,能够缓存每次请求的md5值,或者给每一个请求添加uuid+随机数这样一个表明请求序号的标识。而后请求到服务端时,服务端想办法缓存起来起来这个标识,每次请求过来时,判断是否已经请求过。可是缓存怎么实现,如何维护?并且并发量高的话,每一个请求过来都先查缓存,是否影响性能。url
2.3在请求的参数中和签名结果里,加入时间戳这个参数,业务服务器一方面比较签名结果,一方面根据时间戳,来认证请求的合法性,好比容许请求的时间戳与服务器当前时间,存在20秒的偏差等自定义规则。超过20秒的合法请求,服务器也不处理,防止恶意的重复请求。
2.4时间戳+md51 时间差120s以上表明重复请求,md5写缓存,缓存时长120s(大于等于上面的值就行),判断若是有md5表明重复请求。