前端爬虫攻防之接口签名方案

背景

• 服务端鉴别：服务端根据请求特征、行为等判断请求是否是爬虫或者机器。

• 动态签名：针对每次的请求，根据参数不同，按照一定算法规则动态生成相应的签名，服务端验证签名合法性，主要防篡改。

• 身份验证：需要用户登录，后端在处理接口之前先校验用户信息合法性，然后再处理接口。
  

• 数据加密：针对安全性要求较高的请求做数据加密，比如游戏密令登录，支付转账等。

本文主要探讨接口在使用动态签名的机制下，爬虫与接口的相互攻防策略。

故事开始

牛刀小试

1、 【攻】数据采集 -- 脚本抓取

2、 【防】参数篡改 -- 尾随签名

• 将所有业务请求body参数序列化成一个json。

• body参数和url中的请求参数通过Sign函数md5加密得到签名sign。

• 将签名追加在url 参数中，随请求一起发送。

经过签名处理后，爬虫将参数篡改后发送的请求，接口能够识别出来，并直接拒掉返回。

崭露头角

然而并没有难倒爬虫，url 虽然经过了签名处理，但参数相同的情况下，签名出来的url是固定的。

1、【攻】参数签名-- url 收集

大致步骤如下：

• 用一个数组将每个接口完整地址（含签名）收集并存储起来。
  

• 循环将数组中的接口挨个请求。

收集url过程虽然有点麻烦，但却是一劳永逸的事。

接口侧很快发现之前的策略并没有有效的制止住爬虫，于是做了升级

2、【防】url重复利用 -- 签名引入时间

客户端计算签名时候，请求参数中添加t=当前时间,然后计算签名，当前时间随参数发送到后端，后端校验签名的时间是否在一段时间范围内，如果超过一定时间，则判断签名非法。

大致步骤如下：

• 计算签名时，将当前时间一起算入签名中。
  

• 发送请求时候，将时间与签名放入参数中，一起随请求发送。
  

• 后端可根据签名，验证参数的合法性，根据时间，判断签名有没有过期。

引入时间因子后，签名出来的url在一定时间后会失效。爬虫无法将一个签名长期使用。

针锋相对

爬虫发现请求参数、时间均可在客户端生成，既然不能重复的利用现有的签名，那就自己去生成签名。

1、【攻】动态签名 -- 签名伪造

B、借助 工具 格式化

C、抽取签名函数，爬虫主程序修改参数重新计算签名，然后抓取。

2、【防】客户端伪造签名 -- 引入token

• 服务端收到请求，首先验证cookie 中的token 是否合法，然后验证签名是否合法。

• 服务端在返回数据时，将重新生成token 随cookie下发至浏览器。

SDK中根据token生成签名代码如图：

整个流程大致如下：

• 生成签名时，客户端从cookie 中获取 token 值。将token 值加入到签名规则中。

• 服务端收到请求，首先验证cookie 中的token 是否合法，然后验证签名是否合法。

• 服务端在返回结果时，在cookie 中重新设置新的token。

• 客户端第一次请求，当cookie中没有token时候，服务端返回特殊的错误状态码，sdk 识别这个状态码，会进行第二次请求（第二次会拿到第一次返回的token）。

token 由后端生成，随cookie 下发，客户端无法伪造，也不知道生成规则，无法自给自足伪造签名。

神仙打架

一段时间后，爬虫发现接口失效，排查发现接口并没有增加新的参数，而且发现一个奇怪的现象：

在控制台中抓到一个链接，能正常返回数据。然后将这个链接拷贝出来，在浏览器访问，则提示请求非法。

1、【攻】动态签名 -- 浏览器行为模拟

大致步骤如下：

• 第一次请求，必返回异常（没有token），将返回header 中的cookie 记录下来用于第二次请求。

• 请求中随机构造浏览器ua 等参数，突破后端的反爬策略。

• 从第二次请求开始，每次请求返回的token，用map 存储起来，便于下次使用。

• token 的设计，一千个人就有一千个设计。token 的生成和校验是一个高频行为，所以token的生成要保证高效 、加密，随机、体积小。

• 爬虫与正常用户最大的差别是行为上访问频次不同，如果token 能记录下一个用户在一段时间内的访问频次，那从行为上可以区分出爬虫和正常用户，所以我们token 的设计除了用来校验合法性以外，我们还要记录用户一段时间内的访问频次。
  

• 接口采用9位数组存放token, token中包含随机数，时间，请求量，以及加密校后的校验位置。

• 服务端不对token 做存储，只校验token 的合法性校验。

• t在一定允许时间内，token中的时间不更新，用做漏斗计数，记录用户在这段时间内的访问频次。

token 中采用漏斗计数策略后，从访问频次大致可以区分爬虫和正常访问。从而拒绝掉一些高频流量访问。

3、还有一个问题，如果接口每次都不利用上一次token，token传空怎么处理？

上面代码中：
没有token的请求，我们拿到ip ，将ip转换为32位int,在一个int 的map中加一，并判断map中这个ip是否超过一定阈值，如果超过则拒绝返回。

点到为止

爬虫对着忽有忽无的接口，大致也猜到了接口的一些限流处理。然而并没有难住他。

1、【攻】高频被拒 -- 限流访问

• sdk 代码不宜全部混淆，混淆核心代码就行了。

原始代码：

将核心代码加密

加密的目是为了提高破解的难度，并不是从理论层面去达到代码的不可逆。所以我们加密的选型大致从两个维度考虑。
A、采用市面上已有的不可逆加密（至少不容易）
已有的将代码混淆的加密方案 Eval,
Array,_Number,JSfuck,JJencode,AAencode,URLencode,Packer,JS Obfuscator,My Obfuscate。均可被解密，且都能找到相应的开源解密工具，（不过可以使用两种以上的混淆方式，达到混合混淆，破解也有一定难度）。
上图代码采用的国内的jshaman 加密，不能保证完全不可逆，但至少还没有一个开源的将代码一粘就可以逆回来工具。
B、自己实现简单的可逆加密，但是逆向工程需要自己实现。
例如自己修改jjencode加密算法,然后混淆代码如下图：

首先说明一下，以上代码是可逆的，混淆逻辑就是将jjencode混淆函数中的混淆变量做了一些替换，逻辑上做了一些调整。但替换后有两个好处：

• 无法用肉眼识别是采用的哪种混淆方案。

• 无法用市面上现有的开源解密工具解密出来，除非爬虫精通市面上的大部分混淆方案，然后自己实现一个解密函数。

秋色平分

结尾

作者简介

龚虹宇，2017年8月加入房产事业部。主要负责58商业地产业务与前端基础服务的建设工作。

阅读推荐