分享api接口验证模块

Posted 2020-08-25 安吉吉吉

　　一.前言

　　权限验证在开发中是经常遇到的，通常也是封装好的模块，如果我们是使用者，通常指需要一个标记特性或者配置一下就可以完成，但实际里面还是有许多东西值得我们去探究。有时候我们也会用一些开源的权限验证框架，不过能自己实现一遍就更好，自己开发的东西成就感(逼格)会更高一些。进入主题，本篇主要是介绍接口端的权限验证，这个部分每个项目都会用到，所以最好就是也把它插件化，放在Common中，新的项目就可以直接使用了。基于web的验证之前也写过这篇，有兴趣的看一下asp.net MVC Form验证。

　　二.简介

　　对于我们系统来说，提供给外部访问的方式有多种，例如通过网页访问，通过接口访问等。对于不同的操作，访问的权限也不同，如：

　　1. 可直接访问。对于一些获取数据操作不影响系统正常运行的和数据的，多余的验证是没有必要的，这个时候可以直接访问，例如获取当天的天气预报信息，获取网站的统计信息等。

　　2. 基于表单的web验证。对于网站来说，有些网页需要我们登录才可以操作，http请求是无状态，用户每次操作都登录一遍也是不可能的，这个时候就需要将用户的登录状态记录在某个地方。基于表单的验证通常是把登录信息记录在Cookie中，Cookie每次会随请求发送到服务端，以此来进行验证。例如博客园，会把登录信息记录在一个名称为.CNBlogsCookie的Cookie中(F12可去掉cookie观察效果)，这是一个经过加密的字符串，服务端会进行解密来获取相关信息。当然虽然进行加密了，但请求在网络上传输，依据可能被窃取，应对这一点，通常是使用https，它会对请求进行非对称加密，就算被窃取，也无法直接获得我们的请求信息，大大提高了安全性。可以看到博客园也是基于https的。

　　3. 基于签名的api验证。对于接口来说，访问源可能有很多，网站、移动端和桌面程序都有可能，这个时候就不能通过cookie来实现了。基于签名的验证方式理论很简单，它有几个重要的参数：appkey, random,timestamp,secretkey。secretkey不随请求传输，服务端会维护一个 appkey-secretkey 的集合。例如要查询用户余额时，请求会是类似：/api/user/querybalance?userid=1&appkey=a86790776dbe45ca9032fc59bbc351cb&random=191×tamp=14826791236569260&sign=09d72f207ba8ca9c0fd0e5f8523340f5

　　参数解析：

　　1.appkey用于给服务端找到对应的secretkey。有时候我们会分配多对appkey-secretkey，例如安卓分一对，ios分一对。

　　2.random、timestamp是为了防止重放攻击的(Repaly Attacks)，这是为了避免请求被窃取后，攻击者通过分析后破解后，再次发起恶意请求。参数timestamp时间戳是必须的，所谓时间戳是指从1970-1-1至当前的总秒数。我们规定一个时间，例如20分钟，超过20分钟就算过期，如果当前时间与这个时间戳的间隔超过20分钟，就拒绝。random不是必须的，但有了它也可以更好防止重放攻击，理论上来说，timestamp+random应该是唯一的，这个时候我们可以将其作为key缓存在redis，如果通过请求的timestamp+random能在规定时间获取到，就拒绝。这里还有个问题，客户端与服务端时间不同步怎么办?这个可以要求客户端校正时间，或者把过期时间调大，例如30分钟才算过期，再或者可以使用网络时间。防止重放攻击也是很常见的，例如你可以把手机时间调到较早前一个时间，再使用手机银行，这个时候就会收到error了。

　　3.sign签名是通过一定规则生成，在这里我用sign=md5(httpmethod+url+timestamp+参数字符串+secretkey)生成。服务端接收到请求后，先通过appkey找到secretkey，进行同样拼接后进行hash，再与请求的sign进行比较，不一致则拒绝。这里需要注意的是，虽然我们做了很多工作，但依然不能阻止请求被窃取;我把timestamp参与到sign的生成，因为timestamp在请求中是可见的，请求被窃取后它完全可以被修改并再次提交，如果我们把它参与到sign的生成，一旦修改，sign也就不一样了，提高了安全性。参数字符串是通过请求参数拼接生成的字符串，目的也是类似的，防止参数被篡改。例如有三个参数a=1,b=3,c=2，那么参数字符串=a1b3c2，也可以通过将参数按值进行排序再拼接生成参数字符串。