首页 > 代码库 > 对抗机器人的新思路与方案

对抗机器人的新思路与方案

 

技术分享

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

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

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

  当然简单易识别的验证码,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也许很值钱,但在把它实现之前任何人都可以说这是自己的专利,其他公司做到了吗?

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

欢迎交流^_^

 

对抗机器人的新思路与方案