大话接口隐私与安全

• content {:toc}

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

场景

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

例子：

问题 1. 接口暴露用户隐私信息就相当于在光天化日下裸奔，被看光了

描述：程序猿在做业务接口的时候往往没有保护用户隐私的意识，把用户的隐私信息暴露在外面，一旦被人利用起来会给用户带来麻烦，同时被发现会降低平台的信任度；

防：

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

问题 2. 接口暴露敏感信息，就像把钥匙插在钥匙口没拔掉一样，只要你会开门就能进去

用户参与活动的数据 JSON 集合中不要有活动相关业务逻辑的决定性的数据,如：竞拍出价活动，出价唯一最低者拿奖品，结果获取出价的接口暴露了所有出价的价格统计结果。

防：

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

问题 3.数据被人顺手带走(主业务接口相关 JSON 数据 如：首页商品列表数据)

描述：接口中的 JSON 数据会被其他人拿去做自己的相关的功能；这样就造成了服务器的额外支出

防：

0. IP 请求量限制，时间范围内请求量限制，等各种限制 IP 请求的规则，
   如：统计记录(可以记录到 mongdb 中)，定时监控记录发现请求量大于限制的数量就进行 IP 封杀;
1. 请求头的校验，如：User-Agent 校验请求头是不是 APP 客服端发起，Referer 是不是有来源，来源域名是不是自己的域名地址等(这种方式只能是多一个门槛)；

问题 4.移花接木，恶意修改请求信息(修改参数，COOKIE，请求头信息)

描述：通过修改请求中的参数来发起的请求，如：登陆接口修改用户名和用户密码，进行密码库碰撞等。

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

防：

0. 增加一个签名参数，将参数名进行逻辑的排序组合拼接+秘钥 MD5，然后服务端接受到请求的时候也用同样的逻辑得到签名与签名参数进行对比是否相同，这样可以使参数无法被修改，修改了就提示非法请求。 如： 接口http://www.test.com/go/?actid=1&userid=123 我们可以加一个 sign 参数= MD5(actid=1&userid=123&【secret】)【secret】=秘钥，自己定义。 服务端用一样的逻辑得到密文和 sign 签名进行对比是否一样，不一样就提示非法请求。

1. 整个参数内容进行可逆的加密

2. 限制参数范围，如：支持分页接口，很多人会为了方便使用，加了参数就是 pagesize(一页的数据量)，当没有去限制页码最大值得时候，如果表数据量很大，然后攻击者修改 pagesize 参数为 N 万，然后数据库就奔溃了,相关业务就挂了。

问题 5.影分身术，模拟请求，发起并发请求

描述：通过抓包工具抓到请求后模拟请求，如：模拟每日签到请求，或者直接发起每日签到的并发请求。
温馨提示：当请求并发后如何保证数据的完整性，一致性问题，这也是平时开发很需要注意的问题，传送门我的【大话程序员眼里的高并发】有相关的介绍和解决方案。

防:

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

总结

我们需要提高自己的安全意识，防范于未然，要多站在攻击者的角度来看自己的接口;(让自己有一种被害妄想症的感觉，你就离精神病近了一步，<(￣︶￣)↗ ) 不要做开发需求的机器人，我们是有思想有创造力的开发者;

附加个人开发流程

在评审需求的时候要把业务逻辑问题提出来，并给予解决方案的选择;
确定需求后将整个业务逻辑的梳理清楚，复杂的可以画出流程图;
根据需求设计实现方案，需要考虑性能问题[数据库压力，服务器压力]，安全问题，用文档的形式记录下自己的设计方案。（可以深入到代码层面如何去实现）;
列出需求中功能点，评估出自己的时间，得到总工时;
开始开发，开干;