你的API还在裸奔？一文讲解API攻防安全设计问题

前言

看起来好像先后端分离是个浪潮，原来只有APP客户端会考虑这些，如今连Web都要考虑先后端分离 。这里面不得不谈的就是API的设计和安全性，这些个问题不解决好，将会给服务器安全和性能带来很大威胁 。下面我也是根据本身的一些经历和经验说下本身的一些心得 。

API的设计中，主要考虑两大方面的问题 ：

• 防止API被恶意调用
• API通讯中数据加密的问题

接口的安全性主要围绕token、timestamp和sign三个机制展开设计，保证接口的数据不会被篡改和重复调用，下面具体来看：

Token受权机制：

用户使用用户名密码登陆后服务器给客户端返回一个Token（一般是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，若是Token不存在，说明请求无效。Token是客户端访问服务端的凭证。

时间戳超时机制：

用户每次请求都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进行比对，若是时间差大于必定时间（好比5分钟），则认为该请求失效。时间戳超时机制是防护DOS攻击的有效手段。

签名机制：

将 Token 和 时间戳 加上其余请求参数再用MD5或SHA-1算法（可根据状况加点盐）加密，加密后的数据就是本次请求的签名sign，服务端接收到请求后以一样的算法获得签名，并跟当前的签名进行比对，若是不同，说明参数被更改过，直接返回错误标识。签名机制保证了数据不会被篡改。

因此你的API还在裸奔？

Api有哪些安全问题？----http接口—先后端分离mvvm

1. 数据被抓包窃取
2. 数据被调包篡改
3. 数据被爬取泄露

数据加密

1. 对称加密：DES、AES
2. 非对称加密：RSA

安全够了吗，还有哪些要作？

加密解决了数据上行的安全，然而黑客，直接抓密文来提交，怎么办？

接口签名

接口签名够了吗，还有哪些要作？

接口签名，仅仅依靠参数顺序的排列组合，安全强度不够

身份认证-----token令牌

Token受权机制：用户使用用户名密码登录后，服务器给客户端返回一个Token，并在服务器中缓存此Token。后续服务器收到请求后进行Token验证，若Token不存在，则说明请求无效

身份认证的封装-----cookie隐式携带token

1. 使用tokenFilter统一处理
2. 登录成功，服务器直接种token到cookie中
3. 客户端请求时，须要送token值的加密串，到服务器

总结

安全是一个永恒的话题，随着各大网站全站https的推动，安全也愈来愈被重视。签名设计你们必须有，HTTPS但愿你们有。

欢迎你们一块儿交流，喜欢文章记得点个赞哟，感谢支持！