前言:
随着项目前后端分离的火热，后台开发的重点主要是对外提供接口，那么API接口的安全就是要考虑的问题。本文将针对api安全问题进行探讨。
目录
为什么前后分离需要关注接口安全问题
接口是通过http请求的方式来请求和获取数据的，这样的请求是可以通过抓包工具来拦截请求的，如果不处理的话会有很大的安全隐患。比如获取短信的接口被拦截那么别人就可以恶意刷你的短信流量，上传文件接口被拦截别人可以恶意上传从而导致服务器崩溃。黑客还可以通过Dos或CSRF来攻击服务器，
个人觉得安全措施大体来看主要在两个方面，一方面就是如何保证数据在传输过程中的安全性，另一个方面是数据已经到达服务器端，服务器端如何识别数据，如何不被攻击；所以接口安全还是很重要的。下面具体看看都有哪些安全措施。
攻击方式有哪些
- 常见的web攻击方式有：XSS、CSRF、SQL注入、DDOS、重放。
- XSS(跨站脚本攻击)：对所有用户提交内容进行可靠的输入验证对“<”，“>”，“；”，“””等字符做过滤。
- CSRF(跨站请求伪造 cross site request forgery)：
- 通过伪装来自受信任用户的请求来利用受信任的网站，可以利用你的身份发邮件、发短信、进行交易转账等，甚至盗取你的账号
- 例如：你在A网站登录了账号，在没有退出的情况下访问了B网站，B网站有黑客上传的图片且地址为A网站的接口。如果A网站存在CSRF漏洞那么你在B网站时相当于你时A的登录用户，那么B的图片地址请求的接口就被伪造成你的合法请求。
- 防御：尽量使用POST；cookie设置为HttpOnly；增加token；通过Referer识别。
- 重放攻击：利用抓包工具将请求重复多次发送的方式来达到攻击服务器的目的。可以通过请求时效性来防御。
如何保障接口的安全
1. 数据加密
我们知道数据在传输过程中是很容易被抓包的，如果直接传输比如通过 http 协议，那么用户传输的数据可以被任何人获取；所以必须对数据加密，常见的做法对关键字段加密比如用户密码直接通过 md5 加密；现在主流的做法是使用 https 协议，在 http 和 tcp 之间添加一层加密层 (SSL 层)，这一层负责数据的加密和解密。
2. 数据加签
数据加签就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改；你可能会问数据如果已经通过 https 加密了，还有必要进行加签吗？数据在传输过程中经过加密，理论上就算被抓包，也无法对数据进行篡改；但是我们要知道加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，所以这里的加签可以防止内网中数据被篡改；
3. 时间戳机制
数据是很容易被抓包的，但是经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有不法者不关心真实的数据，而是直接拿到抓取的数据包进行恶意请求；这时候可以使用时间戳机制，在每次请求中加入当前的时间，通过timestamp和redis来限制请求的时效首先根据项目情况设定一个有效时长比如设为60s，当请求到达服务器时首先拿timestamp和系统时间对比，如果在60s内那么timestamp校验通过，如果大于60s那么请求过期。如果只通过timestamp来防重放那么在60s内还是可以重放请求的，所以这样还是不够的。我们还需要设置一个nonce。请求到达服务器时去redis中查找key为nonce:{sign}的string，如果没有就创建这个key并把失效期设置为timestamp的失效期比如是60s，如果有说明在60s内这个请求已经请求过那么这个请求可以判断为重放请求。
4. 白名单机制
如果请求的服务器是已知的，可以在服务端判断请求api的服务器的ip是否是约定好的，例如：A部门（192.168.1.1）和B部门（192.168.1.2）需要通过公网进行远程数据调用（方法XXX）。那么B部门在方法XXX被调用的时候，判断时候和已经保存在redis或者数据库中的A部门服务器ip是否一致，如果一致，则放行，如果不一致则终止调用。
5. AppId 机制
大部分网站基本都需要用户名和密码才能登录，并不是谁来能使用我的网站，这其实也是一种安全机制；对应的对外提供的接口其实也需要这么一种机制，并不是谁都可以调用，需要使用接口的用户需要在后台开通 appid，提供给用户相关的密钥；在调用的接口中需要提供 appid + 密钥，服务器端会进行相关的验证；
6. 黑名单机制
与白名单相对应的就是白名单机制：黑名单是适用于，开放给多个客户使用的一种安全手段，假设你不知道调用方的具体信息，并且不能将全部调用都禁止调，那么可以采用黑名单机制。黑名单是基于公司内部的安全规则来规定的，比如，公司规定，1分钟调用5次，就拉入黑名单等等。
7. 限流机制
此方法是针对服务器的某个具体的方法而言，并不是针对调用者的。具体方法是，假设方法AAA请求量过大。我们可以使用业内开源的一些方法来进行处理，常见的算法有，漏桶限流，令牌桶限流。和计数器限流，这里就不细讲了，感兴趣的可以留言或者百度即可。
总结：
本文总结了一些常用api安全的方法，各位可以基于自己业务的需求，选择性使用即可。过多的限制和判断必然会导致性能的下降和代码维护难度的增加
创作不易，各位的支持和认可，就是我创作的最大动力，
【转载请联系本人】 如有问题，请联系我。欢迎斧正！不胜感激 ！
求点赞👍 求关注❤️ 求分享👥 求留言📪