爬虫没有什么特征，它唯一的特征，就是和真人不一样
笔者坚信 AI 是人类科技革命的未来，那么「数据」就是 AI 的「粮食」，尤其是在大模型时代优质的数据才能训练出优质的模型。所以爬虫与反爬虫已经不仅仅局限在过去商业竞争，隐私信息的领域，随着数据在 AI 时代重要性的不断提升，爬虫对抗也会更加激烈。在这篇文章中笔者就想要结合自己的一点经验，谈一谈作为防守方如何从零开始建设一个反爬虫体系。
范围定义
在开始我们的正式工作之前，需要定义好目标。虽然作为业务方希望杜绝掉所有的爬虫行为，但这是不可能的！作为安全人员在和业务方进行合作时，制定出既保护了数据也不过度影响正常用户体验的目标。
保护的数据是什么
爬虫与反爬虫核心关注的实体是「数据」，所以我们需要定义好我们保护的「数据」类型是什么，常见的数据包括个人信息四要素（手机，姓名，身份证，银行卡号）、居住地址、邮箱等，业务数据包括商品价格，文章内容，评论信息等。这里我们注意一点，对于这些「数据」可以分为主动公开和非主动公开，例如说对于四要素绝大多数平台都不会公开，而商品价格可能就是有限公开的，对于不同的数据类型在做防守时就需要制定不同的目标和策略。
你的对手是谁
作为防守方肯定需要知道自己的对手是谁，因为不同的对手，我们需要制定的目标以及付出的精力肯定也是不同的，下面列出主要的：
- 黑灰产：主要获取个人信息（四要素，地址等等），主要是直接打包售卖，下游消费诈骗等目的，技术水平参差不齐，一切以效率优先，手法一般很脏（黑产比你自己还懂业务）。
- 商业竞对：对于商业竞对，他们有动力，有钱，往往对抗起来也是最为困难的。但是不同于黑灰产的不择手段，商业竞对更类似「正规军」，也有着自己的特征。举个例子：竞对爬虫的技术研究人员需要「产出」去汇报给他的老板，比如正面破解你的设备指纹，而不是像黑灰产可以直接利用低版本绕过，所以说在对抗的时候侧重点还是有所不同的。
- 三方数据公司：类似黑灰产，也是打擦边球来爬取数据，甚至某些公司有 zf 背景，在做处置的时候策略又有所不同。
- 创业小公司：为了生死存亡爬数据，技术水平与个人直接挂钩，手法一般也比较粗暴。
- 练手大学生：为了毕设/比赛/练手的大学生，水平不高同样简单粗暴，有时候会在某段时间集中爆发（eg. 毕业季之前）
- 莫名其妙的爬虫：各种莫名其妙的流量，写的有问题的端上辅助插件，失控的搜索引擎爬虫，甚至是来自自己业务的错误流量（没错，敌人在内部，甚至这种情况还不少，极大影响到流量清洗的难度）
你的最终目标是什么
反爬虫的最终目标是什么，绝大多数情况不是做反爬虫的技术能够单独决定的，需要和相关的业务方打好配合，共同制定一个目标，约定一个合理的范围。否则可能会出现你反爬封杀的很快乐，业务方的流量也被干了下去，这一定我们想要的结果，所以一个合理的「共同」目标是必须的，类似爬虫流量占比低于一定程度、黑市上无人兜售数据、用户体验不受大的影响等等，同样需要根据具体业务来综合考量。
预先准备
兵马未动，粮草先行。在整个防守的流程中，前期准备的工作可能是收益比最为高的，做好了充分的准备再对症下药才不会让自己觉得是在到处救火，所以笔者个人建议有条件下尽量把前期工作做充分。
业务形态
最先做的就是熟悉并且了解业务形态，你的产品提供了哪些如果，只有客户端还是同样有 Web 端，客户端是纯原生的还是混杂 H5 的（虽然大部分都是混杂的，甚至是 flutter 跨平台的，但还是要弄清楚你关注的业务分布情况）；应用使用的是什么协议进行数据传输，是标准的 HTTP 协议还是自建的私有协议；服务端是否有统一接入层，敏感数据经过了哪些业务处理，最终存储在哪里等等。笔者这边建议可以关注数据的整个「生命周期」进行梳理：
1 | 采集->处理->存储->分析->呈现->归档->销毁 |
并在整个流程中重点关注爬虫方最容易接触到数据的节点，然后重点布防。这里简单展示下爬取难度分级，一般根据是否要求登录态，是否私有协议，是否有浏览器指纹/设备指纹，业务存在于 Web/小程序/APP 等标准来区分难度。对于大部分爬虫也是根据难易程度来选择性突破。
| 爬取难度 | 业务形态 | 登录态 | 协议 | 设备指纹 |
|---|---|---|---|---|
| 低 | Web | 无 | 标准协议 | 无 |
| 中 | Web/APP | 有 | 标准协议 | 有 |
| 高 | APP | 有 | 私有协议 | 有 |
资产梳理
资产梳理是一件苦活累活，但是也是必不可少的工作，我们在做处理的时候只能尽量话自动化处理，比如批量的接口扫描等。资产梳理主要有几个维度：
- 产品维度：梳理用户能够直接感知的产品部分，哪些地方用户可以看见，可以操作敏感数据，这些产品入口是否是合理的，不合理的需要推动下线。
- 接口维度：接口的梳理可以分为正向和反向，尽可能覆盖存量的接口，并且提前制定好数据接口规范，来约束增量接口上线，常见的梳理思路包括：
- 基于已知的敏感产品场景去找出对应的数据接口。
- 通过对代码的白盒扫描进行提取接口并根据接口的定义打标。
- 根据接口的线上镜像流量进行打标。
- 应用维度：对于使用敏感接口的服务端应用，有时间精力的话需要审计下数据处理以及存储的过程，看下是否加密存储，脱敏化处理等。
风险浓度
风险浓度值的是爬虫流量占据总业务流量的比例，摸清楚风险浓度有助于我们去观察自己的策略是否有效，应该重点关注哪些业务，但是怎么知道爬虫流量占比其实是很困难的，因为「我怎么知道没有其他爬虫流量没有被识别出来呢？」，「我都知道你是爬虫流量了，我为什么不直接封禁你？」。所以对风险浓度的定义和评估只能是一个大概的因子去协助我们从全局观察，这里给几个借鉴指标来参考：
- 转化率不变原则：例如在电商领域，在一定时间范围内，我们可以大致认定 $转换率 = \frac{下单量}{浏览量}$，通过计算 $理论浏览量 = 实际下单量 *转化率$，然后与实际浏览量进行比较，其中的差值我们就可以大致认为是爬虫流量。
- 周期爬虫理论：爬虫可能存在周期性的特征，如果订单曲线进行乘法加权与流量曲线做差还存在周期性特征，这个周期性流量大概率是周期性爬虫。
当然以上是一些比较抽象模糊的概念，不一定适应每一个业务场景，比如说爬虫流量过少，基本影响不到转换率，但是泄漏的数据又十分敏感不能不管，这就不适合使用转化率不变原则来评估业务的风险浓度，我们就需要通过其他角度来进行分析，比如说使用红蓝对抗来评估风险。
风控水位
风控水位这里笔者指的是已有的风控能力，只有了解了目前手上已有的武器，才能查漏补缺去提升整体水平，这里可以重点关注以下的几个点：
- 服务端风控策略引擎：封禁规则不能直接写在每个业务应用中吧，理想中最好是配合在统一接入层处置。
- 客户端设备指纹：缺乏设备指纹，或者设备指纹比较弱，对于爬虫方来说就是其爬虫成本比较低，反爬方想要针对打击也会更加困难。
- 浏览器指纹：相对于设备指纹，浏览器指纹其实一般都会更弱更加不稳定。
- 验证码系统：虽然通过 OCR，AI，打码平台已经能够绕过大部分验证码了，但是基础的验证码还是可以拦截大量低水平爬虫
- 资产扫描工具：如上文所述，用于资产盘点与风险发现。
- ……
持续对抗
来到我们实际对抗的场景，需要先明确一个核心宗旨，其他具体的策略都是服务这个宗旨的：分层治理，成本对抗。分层治理指的是防爬能力是针对不同水平爬虫的，在建立防爬体系的时候应该先从明面薄弱点出发，针对通用爬虫，再逐渐衍生到复杂场景，专家爬虫。这也是为了提升我们反爬的 ROI，毕竟反爬从整体业务看来是一个低 ROI 的事情，就不要自己增添成本了。
说到成本，其实反爬和广义安全一样，我们无法做到百分百没有漏洞，同样无法做到百分百没有爬虫。我们的目标其实是提升爬虫方的成本，包括机器和人工成本，当爬虫方数据爬取成本高于收益时，整体的爬虫量自然会下降。
Web
一般来说对于 Web 端是爬虫的重灾区，常见的手法就是利用 selenium, phantomjs, 按键精灵等工具来获取对应位置的 UI 元素并且解析获得数据。这种手法利用简单，识别难度大，想要完全杜绝基本不可能。
由于浏览器的特性，我们想要做效果比较好的浏览器指纹也比较困难，很多时候还是要同时依赖参考 IP，UA header，并且还需要考虑一些奇葩的浏览器特征，以及自己业务的一些特征数据比如点击顺序。
- TCP/IP：对 IP 限制，包括频率，历史黑数据，代理 IP 等标签。
- HTTP：对异常 header 做处理，需要历史沉淀。
- 浏览器特征：各种指纹，浏览器 BUG 等。
- 业务特征：有登陆态时对账号的限制；对业务行为做限制，例如直接访问详情页，轨迹等业务特征，这里需要因地制宜不便展开。
除了这些常规的特征的检测，最为主流的还是通过 key 加解密来进行对抗，整体的思路大致就是：服务端生成加密 key-> 下发加密 key -> 前端解密并在请求中带上解密 key -> 服务端验证解密 key。整体的思路大致都是这样的，其中具体的细节例如加密 key 如何生成，是否要存储，并且怎么验证，前端解密算法如何保护（混淆，eval，虚拟机等）等等这里不展开讨论了，都是需要实践中不断升级的。
这里需要注意一点对于 Web 端的对抗核心不是加密足够强大，而是 快！因为前端不涉及发版周期，并且不存在老版本问题，同时由于浏览器的特性其风控因子与设备指纹都不够强，结合这些特点对于反爬方需要做的就是提升反爬策略的变化速度，让爬虫方分析成本无限提高，就算破解了这次的加密算法，但是保护策略变换的足够快，就能让爬虫收益下降。
客户端
对于客户端现在也是一个主流的对抗场景，其中又以 Android 端为主（毕竟很多黑灰产的技术都是在 Android 上比较成熟，并且成本也比较低），现在主流的 APP 很多都是自己魔改的私有协议，这点区别于 Web 端为标准协议，当让 APP 中还是存有 H5 会走比如说 HTTPS 协议，针对不同协议我们需要关注的点也不同。
协议挂
原理：分析协议并逆向接口和参数，一般是 HTTPS 和 WSS 协议为主，然后去脱机调用接口。
如何解决：
- 协议加签：客户端给请求中加签名。
- 挑战响应：服务端发起挑战，客户端需要计算响应值回传服务端，服务端校验响应。
内存挂
原理：读取和写入内存数据；修改原有控制流。一般就是各种 frida，xposed，底层原理就是 plt hook, inline hook 等
如何解决：
- Hook 检测，检测特征；检测内存属性；检测目标对象
- Call 检测，栈回溯
真机挂
原理：群控真机，模拟点击，打码平台，例如 https://github.com/xiaocong/uiautomator 自动化，com.sigma_rt.totalcontrol 群控软件
如何解决：
- 接入 WiFi 扫描，IP，设备聚集性特征
- 软件特征检测
以上是常见的外挂分类，这部分需要做的就是迭代对抗升级，同时做好自保护。除此之外设备指纹的稳定性也会影响防控效果，具体可以参考笔者之前的文章。同时客户端的发版周期也会比 Web 长很多，老版本的风控能力不足也是一个比较严重的问题，可以参考的解决方案包括合理的软件生命周期，内嵌 VMP 虚拟机动态执行代码等方案来加速攻防节奏。
服务端
这里的服务端主要指的是风控规则引擎的服务端，一般对于大公司的复杂业务，合理的部署位置一般是在接入层之后，业务层之前（当让还有其他的业务形态，这里笔者没有那么熟悉，暂时不多讨论了）。接入层的流量进行转发到风控引擎，风控引擎支持各种自定义的流量规则，针对不同的接口上不同维度的策略，这里包括限频，拒绝，验证码等多种处置，同时也会对客户端带上来的设备指纹风控因子进行在线计算，提供给不同的策略使用和消费。风控引擎需要注意的是一定要确保又兜底熔断机制，避免防爬策略大规模误拦截。
溯源复盘
威胁情报
有条件的防守方可以订阅关注一些威胁情报，来避免出现大规模的舆情或者监管事件，比如说各种 TG，暗网论坛，这块可以作为一定的能力补充。同时一些公开的安全分析也要注意，做好及时更新我们的策略，切记不要闭门造车，自己的加密方法和风控参数都被破解光了还不知道。
快速止血
基于威胁情报/流量突变，如何做好快速止血呢，首先要保证业务是正常存活的，如何拦截量暴增，先确认是不是误拦截，如果是误拦截就要在上文说的风控引擎中做好一键熔断，但是注意熔断也有可能造成更大规模的故障，这里就需要做好多次提前的演练来保证救命工具一直生效。如果确实是大规模的爬虫来进行攻击，甚至影响到业务稳定性，又或者是监管审查下来，此时就可能需要牺牲一点体验，该封 IP，该上验证码等止血手段就上，同样这些应急手法需要提前灰度和演练。
溯源手法
对于数据泄漏到被兜售利用的阶段，其实已经很难溯源了，因为可能数据已经被爬虫方进行过一遍清洗，非关注的数据被丢弃了，我们常用的手法包括数字水印，数据蜜罐，数据投毒等，只能说尽量能够溯源到泄漏点。
对于作案手法，一般通过风控因子，聚集性特征来分析还原，但是终端的信息毕竟有限，很多时候整个操作端都不在 APP 运行环境中，例如电脑控制手机留下的显著因子就会比较少。
知识沉淀
随着反爬的不断迭代，我们会有一些知识积累，例如设备指纹库，设备风险库，IP 库，作弊软件样本库等等数据都可以作为后续风控规则的输入，我们也可以根据各自业务的特征来做离线分析，刻画出基线的用户画像，甚至利用知识图谱等技术手段进行团伙挖掘等，这块涉及的知识点也很多这里暂时也不展开分析了。
关键问题
这里我们讨论一些建设反爬体系中需要重点关注和讨论的问题，可能它并不直接决定爬虫的发现，却是我们能够稳定运行推进反爬的关键。
准确率
准确率就是拦截的爬虫中有多少是实锤恶意的，也体现了误伤多少用户，如果误伤率高了，准确率低了，整个业务都是运行不健康的。通常反爬也是需要让步业务的，所以保准确率的优先级是高于召回率的。
- 客诉：一般我们可以用用户的客诉量来体现真实反馈，当然一个客诉可能已经代表有一百个用户的误拦截，所以不要单纯以客诉量来评估
- 滑块通过率：滑块作为较为柔性的处置方式，如果通过率有骤变，或者一直处于高位，我们就需要评估策略是否正常了。
- 打点法：举例比如在详情页对可疑爬虫种识别 Cookie，如果在下单页有大量流入的话，说明识别策略存在问题
- ……
召回率
召回率一般是用来反应策略的强度，但是从现实角度来看，对于爬虫的完整召回率是无法计算的，因为我们永远无法知道实际有多少爬虫总量，我们没有计算的分母，所以通常我们只能利用上述说的类似转化率不变规则来侧面评估，或者有条件的可以做红蓝对抗来进行演练，只要确保蓝军的水平足够高，也能间接说明我们反爬体系的强度。
成本与效果
作为安全的一部分，爬虫与反爬虫最终永远需要考虑的是成本与效果的平衡，无论是哪一方当 ROI 过低时都是说明整个体系是有问题的，随着对抗的不断进化，双方甚至会产生一种微妙的平衡关系，反爬杀不掉全部爬虫，爬虫也无法过于明目张胆。所以在达到尽力 100% 前，还是可以考虑不断优化让成本付出远小于效果，这样就可以达到一个不错的里程碑了。
总结思考
爬虫与反爬虫总是在灰色领域相互搏斗着，深入其中又能全身而出才是真本事，笔者浅薄的经验梳理构建了自己认知，从零开始建设一个反爬体系，继续不断前进提升自我，乐在其中。