对抗恶意机器人/自动化行为的新思路与方案 - r00tgrok

 　　登录博客园时，看到的界面是左边这样的，验证码错了一次之后就变得更加扭曲了。

　　以前博客园不会在第一次访问页面的时候弹出验证码来，这样的体验很不好。

　　验证码作为防机器人的标准套件，已经在无数场合被证实有效。

　　当然简单易识别的验证码，OCR就可以搞定，然后机器人该来的来。

　　复杂一点的验证码，歪歪曲曲的连正常用户都看不清，效果并不好。

　　后来出现的滑动验证码、点击图片的验证码，用户体验和安全性都得到了巨大的提升。

　　随着图像识别精准率的大幅提高，12306曾经遇到过图库被遍历，再调用百度接口识别图片，饶过验证码的问题。

　　即便安全领域做到顶尖水平的Google CAPTCHA就在不久前也被人破解过，有哪家敢说做得比Google还好呢？

　　我只是不喜欢图形验证码，太麻烦了。然而对绝大多数团队来说，如果不用验证码是防不住机器人的。

国外研究Bot行为的公司Distil做得相当不错，还有一家公司叫ShapseSecurity可谓防机器人新技术的业界先驱。他们并没有使用一些很复杂的操作来做这件事情，而是深入到防机器人的场景和原理，从更底层的技术上Anti Bad Bot。

国内更普遍看到的是阿里云、同盾这样的从风控着手的解决方案，比如老外这家叫shieldsquare的公司我觉得思路也差不多，都需要基于海量大数据、云平台、信誉库或者嵌入到应用代码中。并不是说这些做法不好，但如果考虑这样一种场合：Bot使用的IP是多源分布的（10W级别）、请求的频率接近正常人甚至更低、没有任何攻击特征，除非是帐号关联了IP等信息限制异地操作，纯风控层面的解决方案并不理想。从业务层面来看，如果不在黑名单中且行为特征（频率、数据包）无明显异常，那么通过机器人进行批量注册/登录（云打码、短信猫池）、灌水刷评论、领取奖励这些行为，现有风控机制（设备指纹等）最起码是无法实时阻断的。最终你也许可以限制或冻结交易，但大量的虚假信息（比如信用卡申请场景）仍需人工处理，而这样的操作成本是高昂的（信用卡申请需要调用公安系统接口验证个人信息是否属实）。

现在介绍另一种思路和方案，它由国内安全创新公司瑞数信息率先实现（目前唯一）。技术原理上来说，它仍会用到诸如阿里云使用的设备指纹、用户行为信息采集、以及IP信誉库这样的方案，但这只是其中一个环节。在不谈威胁感知、动态智能这样的概念（瑞数也有）时，这个方案防机器人的步骤有四个：

1. 动态封装，对网页底层代码做持续变幻，隐藏页面中的表单信息、链接信息等，隐藏攻击入口。这个步骤可以直接干掉56%的Bot（详见Disktil报告）。

2. 动态取证，获取包括客户端指纹、用户行为记录等等信息，判断发起请求的是人还是机器，兼容市面上99%（保守估计）的浏览器。

3. 动态混淆，使用一次性的加密算法对用户发出的请求内容进行保护，有效阻止中间人攻击，伪造请求、恶意代码注入、窃听或窜改等行为。

4. 动态令牌，通过对当前页面内的合法请求地址授予一次性令牌，可保障攻击者无法绕过业务逻辑发出非法请求，可有效防御越权、重放、Web Shell、应用层DDoS等。

再说一下部署：

1. 置于应用服务器前作为反向代理，支持所有主流应用服务器。

2. 不用改服务器哪怕一行代码、一个配置，客户端无须装插件、控件。

3. 不基于特征识别和规则，％0误阻断，至于是否可能被绕过，我也不能说100%没有漏网之鱼。

4. 防护原理不依赖于海量大数据（如果有当然很好），用户数据不会被传到自己不可控的云端（都在本地）。

5. 如果是移动APP，Native代码需要集成SDK，HTML页面可直接防御。

如果要问我说这功能靠不靠谱、性能行不行，我只能说没经过测试你敢让产品上线么？

另外如果要问我，算法被逆向了怎么办，核心代码又不在客户端，Billion数量级别实时变幻的算法你去逆啊！

关于实现的技术难度，Idea也许很值钱，但在把它实现之前任何人都可以说这是自己的专利，其他公司做到了吗？

利益相关：碰巧领了公司老板好几个微信红包

欢迎交流^_^