Web 端反爬技术方案.zip

# 反爬技术方案的研究与落地 > 对于内容型的公司，数据的安全性不言而喻。一个在线教育的平台，题目的数据很重要吧，但是被别人通过爬虫技术全部爬走了，那结果就是“凉凉”。再比说有个独立开发者想抄袭你的产品，通过抓包和爬虫手段将你核心的数据拿走，然后短期内做个网站和 App，短期内成为你的劲敌。成果：segmentfault 上发表过[文章](https://segmentfault.com/a/1190000017899193)，获赞 152。 ## 一、大前端时代安全性如何做 大前端的数据安全主要分为：客户端、网页端。客户端简单介绍下。 ### 1. 中间人盗用数据 目前 App 的网络通信基本都是用 HTTPS 的服务，但是随便一个抓包工具都是可以看到 HTTPS 接口的详细数据，为了做到防止抓包和无法模拟接口的情况。我们可以采取 HTTPS 证书的双向认证，这样子实现的效果就是中间人在开启抓包软件分析 App 的网络请求的时候，网络会自动断掉，无法查看分析请求的情况 ### 2. 防重放 对于防止用户模仿我们的请求再次发起请求，我们可以采用 「防重放策略」，用户再也无法模仿我们的请求，再次去获取数据了。 虽然话题都是大前端时代的安全性，但是防重放策略篇幅较长，开了新的[章节](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter3%20-%20Server/3.8.md)。感兴趣的同学请移步查看。 ### 3. App 内 H5 网络请求 对于 App 内的 H5 资源，反爬虫方案可以采用上面的解决方案，H5 内部的网络请求可以通过 Hybrid 层让 Native 的能力去完成网络请求，完成之后将数据回调给 JS。这么做的目的是往往我们的 Native 层有完善的账号体系和网络层以及良好的安全策略、鉴权体系等等。 <details> <summary>JS端发起网络请求代码：点击展开</summary> ```Javascript var requestObject = { url: arg.Api + "SearchInfo/getLawsInfo", params: requestparams, Hybrid_Request_Method: 0 }; requestHybrid({ tagname: 'NativeRequest', param: requestObject, encryption: 1, callback: function (data) { renderUI(data); } }) ``` </details> <details> <summary>Objective-C代码：点击展开</summary> ```Objective-C [self.bridge registerHandler:@"NativeRequest" handler:^(id data, WVJBResponseCallback responseCallback) { NSAssert([data isKindOfClass:[NSDictionary class]], @"H5 端不按套路"); if ([data isKindOfClass:[NSDictionary class]]) { NSDictionary *dict = (NSDictionary *)data; RequestModel *requestModel = [RequestModel yy_modelWithJSON:dict]; NSAssert( (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Post) || (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Get ), @"H5 端不按套路"); [HybridRequest requestWithNative:requestModel hybridRequestSuccess:^(id responseObject) { NSDictionary *json = [NSJSONSerialization JSONObjectWithData:responseObject options:NSJSONReadingMutableLeaves error:nil]; responseCallback([self convertToJsonData:@{@"success":@"1",@"data":json}]); } hybridRequestfail:^{ LBPLog(@"H5 call Native`s request failed"); responseCallback([self convertToJsonData:@{@"success":@"0",@"data":@""}]); }]; } }]; ``` </details> ### 4. 中间人攻击 针对抓包工具可以截获 HTTPS 数据的情况，我们可以对请求参数和返回内容再做一次 **RSA** 加密处理。 - 客户端和服务器各自生成公钥、私钥 - 互相交换公钥 - 通信流程：客户端利用服务端的公钥加密请求参数 -> 服务端收到请求后利用服务端的私钥解密，验证合法性 -> 做可能的逻辑处理（DB、缓存、ES）,组装数据 -> 处理数据到合适的格式 -> 利用客户端公钥加密数据 -> 客户端收到数据后利用客户端私钥解密。（服务器主动发起的请求也是一样的逻辑） 有些人觉得利用 RSA 加密虽然可以保证数据的安全，但是因为每次都是大量字符串的运算，觉得数据量大的情况下用 RSA 加解密会非常耗时。 对，肯定耗时，所以较好的做法就是将通信双方使用的密钥（对称加密）利用 **RSA** 的方式交换，然后两方在通信的时候，数据内容采用**对称加密**的方式进行。 但是私钥在本地如何存放呢？想到的办法就是将关键密钥的字符串提高到较高的安全级别，比如这个文件用加密保存。接下来推荐一个[工具](https://github.com/RNCryptor/RNCryptor)，可以将代码文件进行加密保存和解密访问。 ### 5. 自定义报文 数据加密、压缩 + 自定义报文 HTTP 1.1 版本存在大量的 Header 冗余信息，网络传输利用率低。接口可以抓包并模拟请求，安全性较低。基于此可以设计一套数据的加密. 比如 `AES CBC 加密 + ZIP 压缩 + 自定义报文` 这套方案数据既安全又传输高效。 ## 二、爬虫工程师的爬虫手段 要做某个事情肯定需要先现状分析、可行性分析。问了几个爬虫工程师和个人经验，爬取数据主要分为： - 从渲染好的 html 页面直接找到感兴趣的节点，然后获取对应的文本 - 去分析对应的接口数据，更加方便、精确地获取数据 ## 三、制定出 **Web 端反爬技术方案** 从这2个角度（网页所见非所得、查接口请求没用）出发，制定了下面的反爬方案。 - 使用 HTTPS 协议 - 登陆态下，单位时间内限制掉请求次数过多（等级1），则降低频率给账号返回数据 - 登陆态下，单位时间内限制掉请求次数过多（等级2），则返回错误的数据给该账号 - 登陆态下，单位时间内限制掉请求次数过多（等级3），则封锁该账号 - 前端技术限制 （接下来是核心技术） 该方案也可以覆盖 OCR 爬取场景。OCR 的前提是页面渲染完毕，页面所需业务数据需要通过接口获取。所以基于用户行为采集分析，基于日志分析用户在时间范围内的请求频次、用户行为是否正常，如果不正常，说明可能是爬虫程序，依据用户单位时间内情况恶略程度，可以采用降频、返回错误数据、封锁账号的策略。 ### 1. 数据加密 比如需要正确显示的数据为“19950220” 1. 先按照自己需求利用相应的规则（数字乱序映射，比如正常的0对应还是0，但是乱序就是 0 <-> 1，1 <-> 9,3 <-> 8,...）制作自定义字体（ttf） 2. 根据上面的乱序映射规律，求得到需要返回的数据 19950220 -> 17730220 3. 对于第一步得到的字符串，依次遍历每个字符，将每个字符根据按照线性变换（**y=kx+b**），其中，**k 为当前的月份，b 为当月的号数**。线性方程的系数和常数项是根据当前的日期计算得到的。比如当前的日期为“2018-07-24”，那么线性变换的 k 为 7，b 为 24。 4. 然后将变换后的每个字符串用“3.1415926”拼接返回给接口调用者。(为什么是3.1415926，因为对数字伪造反爬，所以拼接的文本肯定是数字的话不太会引起研究者的注意，但是数字长度太短会误伤正常的数据，所以用所熟悉的 Π) 比如要对1995这个字符串进行加密（当前日期为07-24） 1 -> 1*7 + 24 9 -> 9*7 + 24 5 -> 5*7 + 24 最后结果为： 1*7 + 24 + '3.1415926' + 9\*7 + 24 + '3.1415926'+ 9\*7 + 24 + '3.1415926'+ 5\*7 + 24 后端需要根据上一步设计的协议将数据进行加密处理**。**下面以 **Node.js** 为例讲解后端需要做的事情 - 首先后端设置接口路由 - 获取路由后面的参数 - 根据业务需要根据 SQL 语句