爬虫与反爬-接口安全的风控介绍

接口反爬，或者说更广义的接口安全，一直以来都是网站和app绕不开的基础问题。尤其是平台的规模扩大，各种功能性的接口包含的信息量越来越多，这也让各种目的的脚本爬虫有了获利的空间和爬取数据的动力。

而对于一个平台而言，爬虫流量不同于正常流量，基本上无法带来正向的效益（除了搜索引擎爬虫尚且有推广平台的效果），它们对平台的危害是多方面的：

• （1）对平台开发和运维，爬虫大量的恶意请求极大地占用了平台服务端带宽和计算资源，让平台无故增加了运维的成本，一些保护程度较低的接口还可能被爬虫流量撑爆，甚至会连锁反应造成平台的故障。

• （2）对于用户来说，个人的活动和隐私信息或多或少会存放在平台上，爬虫会造成用户的信息泄露，这些信息还可能会被用于诈骗等犯罪活动，导致无法挽回的恶劣影响。

• （3）对平台运营来说，平台上的活动信息被爬取，使得羊毛党团伙能够在第一时间获取到活动的相关信息，大量羊毛党小号涌入活动会挤占正常用户的活动参与名额，不仅危害业务功能的正常秩序，还会造成活动资金被羊毛党薅走，严重降低活动的运营效果。

在B站，目前已知容易被爬虫攻击的接口，包括但不限于视频信息接口、用户信息接口、评论内容接口、直播间弹幕/礼物接口、直播抽奖信息接口、主站活动信息接口等等。

这些爬虫怀着各种各样的目的，游走于互联网的灰色地带，有的是为了获取B站的运营数据（比如视频信息接口爬虫、用户信息接口爬虫）；有的是为了在获利的场景更高效率地薅羊毛（比如直播抽奖信息接口爬虫、主站活动信息接口爬虫）；随着NLP对话模型的火热，甚至会出现为模型提供语料而诞生的ugc内容爬虫（比如评论内容接口爬虫）。

在站外开源的社区内部，也有一些会针对B站的api进行破解的项目，这些项目提供的接口，也会被爬虫团伙研究利用，成为爬虫的技术基础。

为了解决爬虫肆虐的问题，风控、网关、前端、服务端合作推动了接口反爬的事项。而在推动接口安全能力不断完善的过程中，也遇到了不少的问题，同时产出了一些解决问题的探索和思考，下面将通过几个方面来介绍：

• （1）接口安全整体框架结构

• （2）风控接口接入方式改造、爬虫风险感知/识别以及处置能力演进

• （3）网关验签组件的设计和应用

接口流量在整个反爬防控过程中的数据流向如图所示。

在整个请求的链路中，包含了两层异常识别的阶段：一层是网关侧在apigw上部署的验签组件，能够对粗暴的恶意接口调用进行识别并直接拦截请求；第二层是风控侧基于上报的设备、ip、账号等特征构建的异常流量识别策略体系，在识别出现的异常流量后，可以对该请求的主体在前端发起真人校验的处置（验证码、引导登录等）。

具体来说，前端在请求时，首先会经由网关上报数据到apigw，此时验签组件会先解码请求的参数，校验参数准确无误后（校验不通过的请求会被直接拦截），apigw会将流量发送到风控的GAIA引擎，风控策略判定该请求是否有异常，对疑似爬虫的请求，会返回异常信号；前端在接收到异常信号后，会进入验证交互流程，通过拉起验证码/登录弹窗、请求验证网关/账号鉴权的方式对用户进行真人校验。

这样的部署，请求的流量通过apigw作为中转直接到达风控平台，其中异常流量能够被拦截在服务网关之前，一定程度可以起到对业务服务的保护作用。

gaia风控引擎最初的数据接入方式，是将风控服务接口提供给业务方的服务端，双方约定好传参和接收参数的格式和类型，服务端开发对接口进行改造发版，将业务的数据上报到风控完成一次风险判定。这种方式的优点在于可以分析每个业务接口的特点，针对性地在业务数据上报时追加差异化特征，但是需要消耗较多的人力，应对接口较少的业务方效率尚可。

但是在对接接口反爬时，需要面对的是平台内数以百计到千计的接口，不仅数量众多，且负责的业务方也各式各样，逐个提需求效率极其低下，无法满足整体的接入效率。而在接口反爬的背景下，识别爬虫流量并不需要过多的业务特征，因此能否构造一套通用化的流量收口方案成了亟需优先解决的问题。

apigw作为平台流量整体的入口门户，会在服务端的网关之前承接大量的接口数据流，因此如果可以在apigw上加上数据上报风控引擎的能力，就能直接通过apigw将流量转发到风控，而不需要在各个业务的服务端单独开发上报数据给风控。

因此为了解决现有风控引擎接入效率低下的问题，风控平台与apigw进行了深度合作，将风控的接口集成到了apigw，让场景流量尽可能在apigw进行收敛，所有通用化的设备参数（ip、buvid、ua、referer等请求头信息）也都整合在apigw的上报数据流中。

在改造了数据接入流程后，在两方面有了改善：

• （1）平台资源成本上，被判定为异常的流量在apigw处会直接阻断，不进入下游的业务网关，降低了服务网关的资源消耗。

• （2）风控接入效率上，从人工代码改造+发版变为apigw配置通用风控项（无代码开发和发版要求），服务端流量接入风控的效率得到明显提升，从每周2~5个接入的效率，提升到一天可完成10个以上接口流量接入。

接口流量接入风控引擎后，需要根据真实的流量数据感知接口当前被刷的风险以及对具体的异常流量进行识别。

风险的感知使用了短线的近实时监控告警，短线监控主要用于感知突发的流量攻击和异动，能快速定位到某个时间段存在爬虫活跃并针对性部署策略。风控侧目前配置了流量激增和特征分布波动的监控告警，用于捕捉异常的流量。

（1）流量激增监控告警：正常的流量曲线通常呈现周期性潮汐趋势，而被爬虫攻击的流量曲线，经常会出现大量突刺，甚至有些极端的接口90%以上流量都为爬虫，会变成毫无周期波动的直线。当接口流量出现激增时，可能是出现了爬虫活动，也可能是某个突发事件引起了流量异动，都会触发告警。

^{接口流量异常激增}

（2）特征异常波动监控告警：爬虫流量基本都是通过直接调用接口的方式生成，绝大部分都存在或多或少的参数异常，因此一个接口内如果某些特征缺失的流量变大，也很可能标志着该接口被爬虫攻击。因此风控构建了“设备id非法占比分布”、“ua非法占比监控”等多种监控，用于感知异常流量，同时也用于对接口当前爬虫风险的简单评估。

^{接口设备异常占比高，绝大部分都是聚集的异常流量}

在感知到异常流量存在后，便是构造逻辑识别哪些流量是异常流量。由于反爬接入的接口数量众多，且接入节奏较快，现阶段的风控逻辑还是以实时的识别策略为主，通过“短平快”的策略更新迭代，来达到防控的效果。

接口反爬不同于以往的活动反作弊、视频互动防刷量，很多爬虫刷子是直接调用接口来获取数据，请求呈现出非登录、参数缺失、参数取值变化快的特点，因此围绕参数的缺失和聚集，构建了一系列通用策略规则集合。

逐个接口进行风控策略的定制会拖累整个防控的接入效率，在前期部分接口接入的经验基础上，沉淀下来一批准确率高、泛用性强的规则，并形成若干规则组。在新接口接入时，自动配置这些规则组，在人工简单确认其中某些规则的识别量和准确性后，即可逐步灰度上线。

异常流量经过上文中的策略识别出来后，还需要结合风控的处置能力才能对黑产进行打击。因为处置的本质是对用户的应有权利进行限制的过程，同时应考虑不要影响正常用户体验，所以在处置能力的构建上，需要我们结合业务性质、策略准确率及用户风险程度高低等因素进行多样化设计。

最初的风险流量处置能力较为单一，基本上仅以验证码为主，这种验证方式能够限制大部分技术能力较弱的爬虫。但是在与黑产对抗的过程中，很快就发现部分异常流量批量通过了验证，但是在验证过程中返回的参数明显为非真人行为，表名爬虫通过某种模式匹配的方式破解了人机验证：

^{关注接口异常流量批量通过验证，但上报的url均统一为异常的网址字样}

随着对爬虫对抗的加深，我们渐进地构建了包括验证码、数据投毒、登录弹框等多种处置手段，基本可以满足99%的业务风险处置。这些主要手段如下表所示（仅列举爬虫用到的处置手段）：

以下是验证能力在整个接口请求中交互方式：

^{验证码手段处置流程}

其中验证部分的流程为：

• （1）用户请求通过APIGW请求风控判断，返回验证(极验/真爱/短信等)决策

• （2）用户客户端通用请求库识别接口返回的验证code，通过验证SDK代理请求验证网关register接口根据不同验证类型请求对应验证引擎拉取验证题目

• （3）用户页面完成验证答题，提交验证答案

• （4）验证SDK代理请求验证网关validate接口根据不同验证类型请求对应验证引擎校验答案

• （5）针对极验验证通过的请求，额外请求风控引擎进行异常判断(识别打码平台等通过的请求)

• （6）结合4&5结果返回验证结果给客户端，异步上报流量到风控引擎，针对性验证加白至特征库

用户在web端访问B站页面时，web页面通常是通过脚本语言访问后端的数据接口以提交数据和获取数据。然而在现有技术中，web端提交数据的方式是直接通过数据接口发送明文到服务器，该方式存在以下安全隐患：

• 一是在通信通道中没有任何加密的明文很容易被窃听者截获，安全性不高；

• 二是攻击者通过分析脚本语言很容易就明白接口协议，进而模拟接口调用爬取接口数据，甚至可以进行接口数据篡改，通过网站服务进行欺诈、作弊。

如果能对明文的参数进行加密，并且在服务端做校验，可以有效防治固定代码爬取平台数据的爬虫脚本，并且校验的结果也可以作为标签特征提供到风控平台作为策略的一个因子，增强风控的效果。

因此在调研了接口加密、接口安全性校验、数字签名等技术方案后，网关侧构建了一套基于混淆密钥加密的数字验签方案，用于对部分功能重要、容易被调接口攻击的接口进行加密验签，作为风控侧前置的异常流量防控手段。

从验签的视角看，接口安全的整体架构如图所示：

其中包含了4个大的模块：验签SDK、web网关、业务网关、风控平台、前端。

（1）验签SDK：负责下发、验证、限流、数据上报功能。

• 下发：维护密钥的定时生成，脱敏下发；支持多版本，灵活密码本。

• 验证：时间戳有效性校验，验签加密校验，风控决策，自动豁免逻辑。

• 限流：提供自定义非白referer、UA等信息接口级别限流

• 上报：验证数据上报，用于监听验签成功率波动，接口验签结果数量，一旦数据异常可以替换为新的密码本

（2）web网关：提供脱敏密钥下发接口。

（3）业务网关：本地引入验签SDK的验证部分。

（4）风控：可以根据网关上报的验签数据作为特征，构造策略进行决策并返回决策结果。

（5）前端：在浏览器中维护和更新脱敏后的密钥，实现加密算法接入到web页面中。

该结构有安全性高、可配置化、高性能、低成本、高容灾性的特点：

• 安全性：服务端通过随机加密方式生成密钥，并通过密钥索引表来进行混淆。

• 配置化：接入加密SDK后，在配置中动态注入加密接口，动态调整验签和拦截状态。

• 高性能：接口验签过程都在内存中进行计算，不需要额外的网络调用。

• 低成本：为了快速上线和迭代，一期实现方式是全量用户共享同一套密钥

• 容灾性：当出现大面积验签失败时会自动豁免，防止正常用户被误伤。

首先，Web网关会定期生成原始加密密钥，并设置过期时间，然后通过接口下发给前端，前端获取到原始密钥后根据密钥索引打乱、混淆后生成最终的密钥。前端在请求接口时，根据请求参数、当前时间戳、密钥，生成签名sign追加到请求参数中。服务端根据相同的算法验证签名的有效性，并上报到风控，结合风控结果判定是否需要对请求进行拦截。

整个加密验签经历密钥生成、密钥下发、密钥混淆、构造签名、网关验签这5个步骤。

• （1）密钥生成：web网关的job服务会定期生成一对密钥，存储到Redis。

• （2）密钥下发：在web页面加载的首个接口，会进行密钥下发。

• （3）密钥混淆：通过字段位移、加盐、映射等方式，将密钥做一层混淆。

• （4）构造签名：通过对参数拼接、裁剪，并用加密算法将参数组转换成key。

• （5）网关验签：网关服务在收到前端的请求后，根据相同的加密算法对参数和密钥整合计算出正确的签名，并与前端提交的签名进行校验，从而判断是否是合法的请求。

正常接口的反爬效果，可以通过使用短线和长线方式进行检测，从定性和定量两个角度来评估接口的风险情况。

（1）定性-消峰评估：在需要快速迭代时，通过观察异常激增突刺的接口，认为是存在明显爬虫攻击的接口，并且在接入风控前和风控策略部署后的通过流量曲线是否平滑来定性该接口风险是否消除。

^{读取关注列表接口：风控接入前存在较多突刺，接入后曲线趋于平滑}

（2）定量-检测指标评估：通过多个构建规则组合的检测指标，量化接口的流量、打击量以及检测量和检测召回率。

目前接入风控的接口，每天识别异常请求量达到亿级别以上。接入的场景中，随着打击的策略不断迭代，召回率也有了明显的提升，重点接口防控的召回率达到了85%以上。

另外，从爬虫攻击造成的恶性事件来看，在风控拦截能力逐步部署后，加上基建平台的运维侧加强了接口安全和服务可用性的建设，23年Q3未出现由于爬虫攻击引发的服务异常崩溃。

平台的部分接口由于业务功能特殊性，爬虫的形式与普通接口存在较大差异，比如点赞接口、直播营收下单接口，都是写接口，但也会被人通过脚本恶意刷接口，又比如直播长连接接口，需要借助请求中带有的直播间信息来判断是否异常。此类接口需要结合业务事件，通过对于业务带来的收益评估效果，下面将以直播长连接建连、金瓜子兑换、关注三个接口的防控案例来说明。

直播长连接在连接建立后，平台的广播服务会不断向建连的终端下发消息流，该建连接口被黑产大量用来抓取直播间的弹幕、用户进房、主播收益等数据。直播建连接口防控，风控与直播服务端、长连接中台进行了深度的合作，采用了下发消息采样的方式（也是mock数据的一种形式）对风险建连请求进行处置。

在经过一系列的风控策略和直播服务端功能改造，目前直播长连接日均处置千万级别连接请求，直播建连数日均降低25%。定期监控的若干爬虫网站，目前均已处于关停或者数据异常状态。

在排查金瓜子下单接口风险时，发现一批黑产小号的异常行为：1）每日固定时间段进行低金额的相互打赏；2）每日固定时间段会批量调用金瓜子兑换接口，将金仓鼠兑换为金瓜子。

通过摸排上游行为链路，发现这批账号在直播活动中进行自动化的批量作弊，其作弊模式为：自动化打赏、评论完成开播激励的每日任务，最后去违规获取直播里程碑奖励（比如游戏cdk）。

^{直播活动作弊黑产链路}

通过对该作弊链路上的挂播、异常金瓜子兑换、异常打赏等行为识别，抓获到一批的作弊用户，并联动直播活动运营进行处置打击。

关注接口实时接入风控后，分析数据时发现该接口会存在频繁的批量攻击，在攻击时流量呈现明显的突刺情况。

结合用户的基本信息和关系链数据分析，发现这些关注均来自恶意引流账号，通过关注增加自身曝光，目的是将用户引流到三方的非法网站或者app。行为链路为：

^{引流黑产批量关注作案链路}

联动注册、登录、关注等场景，基于账号和设备关联，定制化构建了若干识别策略，挖掘到一批黑产小号并处以相应的处置。

通过近两个Q的风控能力建设，接口反爬项目已经初步形成了接入流程快捷、风险感知及时、层次化、风险处置模式多样、打击结果可复盘的一体化风控模式。总结来说，在整个反爬项目的推动过程中，遇到了不少痛点，在其中的一些问题上也总结了相应的解决思路。

但由于前期工作较为耗费人力，未能将各个环节打磨精细，不少模块还处于可用状态，尚未达到极限，在后续的项目演进中，至少还有以下几个方面可以进一步升级完善：

（1）推广轻量引擎在反爬中的应用：全平台的整体流量巨大，风控的普通引擎复杂的因子计算和判定逻辑无法承接超高QPS业务，因此衍生出了轻量引擎。目前轻量引擎在少数几个接口中试点完成，可进一步应用到其他大流量接口。

（2）高级爬虫手法的感知和风险评估指标：现有的爬虫风险的评估手段主要基于事中的异常检测，但对于低频或者单账号长期的数据爬取模式识别能力较弱，仍然需要探索结合事后行为特征的更客观、更全面的评估方式。

（3）风控识别能力智能化、模型化：目前受限于前置能力部署，爬虫的识别方式基本集中于各种特征的挖掘和规则的堆叠。在规则部署达到一定程度后，爬虫会变得更加隐蔽，规则的边界效应会有所下降，因此需要探索对正常用户和爬虫用户的差异，通过行为序列、介质网络等模型能力来发现更高级的爬虫模式。

关于接口反爬和平台信息安全，大家在跟爬虫对抗中遇到过什么有意思的痛点，有什么防控经验和解决方案吗？欢迎在留言区告诉我们。转发并留言，小编将选取1则最有价值的评论，送出日版赫斯缇雅手办景品一个（见下图）。12月22日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！