API崛起下的Bot管理

API将是未来企业核心对外的业务接口,这导致了Bot流量占比继续大幅度上升。一方面,增加了业务与业务之间正常的交互;另一方面,催生了背后附加的黑灰产的蓬勃发展。

近几年,应用安全领域的新技术、新厂商如雨后春笋般地涌现。该领域之所以会如此快速地发展,一方面,得益于nginx及OpenResty高扩展性的设计,使得技术团队可以专注于特定安全问题,并且快速开展攻防能力的研发,不必投入驱动级HOOK、内核协议栈修改以及用户态的HTTP协议解析代理等这些复杂而又晦涩的底层技术领域;另一方面,应用是承载着信息交互的实际桥梁。随着信息化浪潮的来临与科技的进步,云、大、物、移作为基础设施逐渐完善,企业必然有更多的业务通过应用(web、移动、人工智能机器人)对外提供。诸多因素推动当前应用开发模式在迈向devops及API服务化。在新模式的原始阶段,安全的诉求会接踵而至,鉴于绿盟科技在Bot管理领域的技术积累,本文希望与应用开发及应用安全领域的从业者进行交流。

我们先引用一些咨询机构在应用安全领域报告中的摘要:

到2023年,网络中Bot流量的比例将会超过“人的请求流量”。

到2022年,API滥用将转变为最常见的攻击方式,从而导致数据信息泄露,这将成为Web企业面临的严重问题。

到2021年,将有90%的Web应用程序以API而非UI的形式面对网络攻击,其占比远远高于当前2019年的40%。

可以看到,API将是未来企业核心对外的业务接口,这导致了Bot流量占比继续大幅度上升。它一方面增加了业务与业务之间正常的交互,另一方面却催生了背后附加的黑灰产的蓬勃发展,猫池、接码、打码平台等一条龙工具随着API的启用,更加便捷、灵活。

  1. Bot模拟正常人操作实现下面的请求更加难以识别:
  • 信息泄露:内容爬虫、价格爬虫
  • 漏洞探测:自动化扫描
  • 账户安全:信用接管(暴力破解、撞库)、恶意注册
  1. 业务安全防护的难度更高:
  • 交易欺诈:虚假交易、薅羊毛
  • 恶意竞争:库存囤积、黄牛党
  1. 从面向HTML格式的URL攻击,变身为针对XML/JSON的攻击脆弱性更明显:
  • API滥用:短信轰炸、拖库
  • 信息泄露:数据遍历、批量获取
  • 身份越权
  • 恶意访问

Bot演进路线

以前对抗这类黑灰产,Bot识别是核心工作。一般应有几个层级的图灵测试:

  1. 简单脚本 — 爬虫、Python脚本

一般爬虫和简易的Python脚本工具等都不具备JS脚本的执行能力,通过在流量中注入JS,验证客户端脚本执行能力来进行识别。

  1. 一般工具 — PhantomJS 扫描器等工具

PhantomJS和主流扫描器(Appscan、AWVS、RSAS等)都集成了JS解析引擎,因此都能够执行JS脚本,我们需要通过随机选取W3C规范中的浏览器属性以及各个不同浏览器的特殊属性进行组合来判断客户端是否为真实的浏览器。

  1. 高级工具 — seleium + Webdriver

Webdriver是目前使用最多的前端自动化测试工具,它能够打开一个真实的浏览器并通过脚本来进行操作。在识别这种高级工具时,我们需要通过监听操作事件来获取操作特征,比如:鼠标移动轨迹、按键频率等,判断是否为真人操作。

  1. 专业工具 — seleium + Webdriver + 模拟操作特征

在黑产专业工具中,攻击者一般会通过代码来模拟真人操作触发相应的事件,这种情况下,我们建议结合API,将收集到的操作特征数据,基于API进行聚类,来判断是否为真实的人工操作。

而在API环境下,上述通过下发JS来实现层层递进的自动化工具检测,有些场景却无法完成校验工作。经过研究调用,目前发现了一种技术手段可以对该类问题进行解决——将API调用顺序,抽象为场景模型,结合业务的理解,标识意图为Bot的流量:

  1. 基于Bot行为特征进行初步分类
  • 利好Bot:搜索引擎、合作伙伴、第三方服务
  • 中立Bot:爬虫、不明意图机器人
  • 恶意Bot:恶意评论、垃圾邮件、价格/库存爬虫、扫描器、恶意抢购
  1. 将Bot行为及业务特征进行联合分析
  • 记录Bot行动轨迹,结合网站业务特征来分析机器人的行为特征。例如机器人访问的都是商品页面,还是频繁地提交同一个/一组表单;或者是无意义的访问了很多404页面。

同时,可视化呈现各类已识别意图的访问轨迹、行为和特征属性,帮助用户结合业务挖掘哪些业务是Bot最主要的目标,能够获取怎样潜在的利益。完成API环境下跟黑灰产的对抗及处置。

此外, WAF、API安全与Bot管理三位应用安全成员未来的关系,也是困扰咨询机构和国内外WAF大厂的一个问题。两家咨询机构Forrester和Gartner持有的意见各有侧重,而Akamai、Imperva、F5三家曾作为leader象限的厂商,应对方式也不尽相同。到底会融为一体、还是组合成WAAP解决方案、或是独立存在,还需要随着技术和环境的演进慢慢得到统一。笔者团队也多次讨论过这个问题,我们更倾向于形成WAAP平台——支持WAF、Bot管理及API防护几个组件在公共资源、受限资源和内部资源间进行选择性部署,形成不同的防护等级,具备多种安全能力联合组合解决方案,为应用提供分层递进的安全体系架构。讨论的观点主要有:

  1. 这两种防护能力是无法进行替换的,Bot管理虽然可以通过页面混淆使得扫描器无法扫描成功,但它仅仅是一个针对机器人的迷宫,如果后面的数据没有一道实在的“墙”在前面检测攻击,正常人无需任何额外技巧,可以直接绕开这种防护能力。
  2. 规划防护资源的视角不同,如前文所述,Bot管理是基于同一个域下不同业务类型进行管理的,如登录、活动、服务集等,而WAF则面向站点的开发语言和中间件。这会导致配置无法归一。
  3. Bot防护的核心在于管理,根据Bot类型和活动情况,分别、分时调整,这是一款中度使用的产品,并应具备以下管理手段:
  • 限流:最通用也是最温和的一种方式。对于机器人操作者来说,只是网站的访问速度变慢了;但对于企业来说,是在不打草惊蛇的基础上,缓解了机器人造成的资源浪费、释放了服务器资源。限流措施适用于第三方服务机器人、不明意图的机器人等类型。哪怕是扫描器类型的机器人,有些时候限流措施都比直接封堵要更加适合。
  • 欺骗:对于抱着特定目的而来的机器人,欺骗措施非常适用。例如对于价格爬虫,可以通过欺骗的方式,返回给爬虫一个错误的价格,诱导竞争对手设置错误的价格。而此时竞争对手完全意料不到自己获取到的是错误信息。
  • 引流:当机器人流量太大以至于确实影响到了正常的业务流量时,可以通过引流的方式,把机器人流量都分流到空闲服务器或其他业务服务器上,从而缓解业务高峰期的压力,为优质用户提供更好的用户体验。
  • 提醒原站:此方式非常适用于业务逻辑复杂的场景,避免网关类型的设备过多地介入业务逻辑带来的配置难题。此时只需要告诉源站,哪些请求可能是机器人流量,由源站结合此信息来判断响应内容。例如优惠券抢购活动,通过提醒源站,源站可以给机器人流量返回高折扣的优惠券。这样既不会减少活动热度(点击率),又不会造成业务损失,为企业热门活动节约了成本。
  • 二次校验:类似于验证码机制,在有风险的情况下,增加二次验证,避免正常客户业务无法进行,又增加了黑灰产进一步获利的难度。

因此,在恰当的时机调整WAF、API安全及Bot管理产品的技术规划路线,进行WAAP的预研及devops环境的对接,应当可以在应用开发快速发展的未来,持续提供足够的安全保护能力。

联合作者:刘书浩、詹圣君、盛得祥、查文静

发表评论