开放API 防止恶意调用纪实

开放API 防止恶意调用纪实

简介：我们公司网站属于知识产权+电商性质的平台，平时用户量并不是特别大。一开始我们并没有做太多的网站安全验证工作，只是简单的实现了IP黑白名单的控制。
2019年04月份开始，系统监控数据显示，平台有几个API被高频率恶意调用。刚开始发现是我们采取的应对措施是：将该请求IP加入到黑名单，禁止该用户继续访问我们的系统。半天之后我们发现用户更换了一个ip又继续刷。很明显，黑白名单对这类专业玩家是没有作用的，于是一段持久的攻防战拉开序幕。

第一次升级

升级内容

1. 通过js对请求参数进行md5摘要，防止参数被篡改。
2. 限制每个ip的访问次数，当一个ip访问次数等于N的倍数时，要求客户属于验证码。
3. 提供随机字母+数字的验证码

取得效果
在升级后的第三天，我们发现系统又被恶意攻击了，对方通过伪IP的方式，躲避验证码的限制，继续风控的访问我们的系统。

第二次升级

升级内容

1. 每自然小时访问次数超过k次时，继续调用，每次都要求属于验证码，当天总访问量超过M次时，每次访问都要求属于验证码。
2. 请求头判断refer属性是否满足要求，如果不满足直接返回一个mock的值给调用方。

取得效果
升级后的第5天，那个可恶的家伙又来了，这一次对方已经破解了我们使用的随机字母+数据验证码，又一次期无忌惮的疯狂的调用我们的API。

第三次升级

升级内容

1. 验证由随机字母+随机的方式，升级问简单数学问题，两个数据的随机加减

取得效果
这一次升级后一周的时间内对方仍有不断的试探动作，估计是在尝试破解我们的问题验证码。
老实说：这种问题验证码破解起来仅仅比字母+数据的方式难度提高一点而已，依旧可以通过程序来进行计算，并不可靠，于是我们决定在对方破解之前再一次升级。

第四次升级

升级内容

1. 将简单算术验证码改为随机汉字点选验证码。实现点选随机汉字验证码

取得效果
自从升级以后未见对方再有试探性动作，可以说双方的攻防战暂时告一段路，我方取得了暂时的胜利。

注：我们提供的是开放的服务，所以我们要保证服务的可用性同时还要保证服务的体验性。在对方使用大量肉鸡攻击我们的情况下，我们是无法避免对方恶意调用的，我们能做的仅仅是增加对方犯罪的成本，让对方觉得无利可图自动立场。