首页 > 代码库 > 对抗机器人的新思路与方案
对抗机器人的新思路与方案
登录博客园时,看到的界面是左边这样的,验证码错了一次之后就变得更加扭曲了。
以前博客园不会在第一次访问页面的时候弹出验证码来,这样的体验很不好。
验证码作为防机器人的标准套件,已经在无数场合被证实有效。
当然简单易识别的验证码,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也许很值钱,但在把它实现之前任何人都可以说这是自己的专利,其他公司做到了吗?
利益相关:碰巧领了公司老板好几个微信红包
欢迎交流^_^
对抗机器人的新思路与方案