大话接口隐私与安全

控制思维

作为后端程序猿自己写的接口就像自己的孩子一样，尽然制造出来了，那就要对他以后的人生负责到底；
随着业务的壮大，需要支撑业务接口也越来越多，使用的用户量变大，虎视眈眈的黑客们视机而动，总是在业务中寻找着可以窃取他人利益的入口，所以我们应该多考虑安全性问题，防范于未然。

场景
服务端程序猿根据需求开发出业务相关的接口，用来满足需求中用户和服务器交互的功能，提供给前端或者客户端（PC端软件，APP端应用）使用， 大部分程序猿在开发接口的时候就仅仅去考虑如何实现业务上的逻辑功能，而往往很少会去考虑接口的安全性问题， 一般服务端提供的接口都是http/https协议的，通过Fiddler，Wireshark，Charles等抓包工具，可以抓取到请求，然后进行分析，模拟请求，进行并发请求，或者修改信息的攻击。

例子：
问题1. 接口暴露用户隐私信息就相当于在光天化日下裸奔，被看光了
描述：程序猿在做业务接口的时候往往没有保护用户隐私的意识，把用户的隐私信息暴露在外面，一旦被人利用起来会给用户带来麻烦，同时被发现会降低平台的信任度；

防：
1.用户隐私数据加密，加*号，如用户的相关数据的JSON中有用户手机号，用户邮箱，支付账号，邮寄地址等隐私数据；
2.用户请求接口时需要对其隐私参数加密：如用户登陆请求登陆接口，需要将用户密码进行可逆加密，以免接口被恶意代理捕捉请求后获取明文密码；
3.分享出去的地址中不要用明文的用户ID，或者用户登录的token


问题2. 接口暴露敏感信息，就像把钥匙插在钥匙口没拔掉一样，只要你会开门就能进去
用户参与活动的数据JSON集合中不要有活动相关业务逻辑的决定性的数据,如：竞拍出价活动，出价唯一最低者拿奖品，结果获取出价的接口暴露了所有出价的价格统计结果。

防：
数据中需要将敏感字段,或者对业务有着决定性作用的字段中的部分字符串加*;

问题3.数据被人顺手带走(主业务接口相关JSON数据 如：首页商品列表数据)
描述：接口中的JSON数据会被其他人拿去做自己的相关的功能；这样就造成了服务器的额外支出
防：
1.IP请求量限制，时间范围内请求量限制，等各种限制IP请求的规则，如：统计记录(可以记录到mongdb中)，定时监控记录发现请求量大于限制的数量就进行IP封杀;
2.请求头的校验，如：User-Agent 校验请求头是不是APP客服端发起，Referer 是不是有来源，来源域名是不是自己的域名地址等(这种方式只能是多一个门槛)；

问题4.移花接木，恶意修改请求信息(修改参数，COOKIE，请求头信息)
描述：通过修改请求中的参数来发起的请求，如：登陆接口修改用户名和用户密码，进行密码库碰撞等。

温馨提示：
修改请求参数可能会导致很多安全性问题，如：SQL注入，XSS 跨站脚本攻击等
以下方案都针对客户端，如PC软件和APP，WEB端JS去做加密的话不是很推荐，JS代码是暴露出来的，所以如果用JS做加密一定要混淆JS代码

防：
1.增加一个签名参数，将参数名进行逻辑的排序组合拼接+秘钥MD5，然后服务端接受到请求的时候也用同样的逻辑得到签名与签名参数进行对比是否相同，这样可以使参数无法被修改，修改了就提示非法请求。 如： 接口http://www.test.com/go/?actid=1&userid=123 我们可以加一个sign参数= MD5(actid=1&userid=123&【secret】)【secret】=秘钥，自己定义。 服务端用一样的逻辑得到密文和sign签名进行对比是否一样，不一样就提示非法请求。
2.整个参数内容进行可逆的加密
3.限制参数范围，如：支持分页接口，很多人会为了方便使用，加了参数就是pagesize(一页的数据量)，当没有去限制页码最大值得时候，如果表数据量很大，然后攻击者修改pagesize参数为N万，然后数据库就奔溃了,相关业务就挂了。

问题5.影分身术，模拟请求，发起并发请求
描述：通过抓包工具抓到请求后模拟请求，如：模拟每日签到请求，或者直接发起每日签到的并发请求。
温馨提示：当请求并发后如何保证数据的完整性，一致性问题，这也是平时开发很需要注意的问题

防:
1.模拟并发请求，IP限制同上问题2的解决方案。
2.请求信息带上时间(可逆加密的时间)，服务端获取时间，超过限定时间的返回请求超时(目的使抓取到的请求不是一直有效的)。
3.用户token,等标识用户重要的信息数据，保存COOKIE需要设置过期时间，或者加密的明文里要有创建的时间，服务端做对应的时间失效的限制，这样即使COOKIE被别人盗取，模拟请求也会随着时间而失效;