【🏠作者主頁】：吳秋霖
【💼作者介紹】：擅長爬蟲與JS加密逆向分析！Python領域優質創作者、CSDN博客專家、阿里云博客專家、華為云享專家。一路走來長期堅守并致力于Python與爬蟲領域研究與開發工作！
【🌟作者推薦】：對爬蟲領域以及JS逆向分析感興趣的朋友可以關注《爬蟲JS逆向實戰》《深耕爬蟲領域》
未來作者會持續更新所用到、學到、看到的技術知識！包括但不限于：各類驗證碼突防、爬蟲APP與JS逆向分析、RPA自動化、分布式爬蟲、Python領域等相關文章

作者聲明：文章僅供學習交流與參考！嚴禁用于任何商業與非法用途！否則由此產生的一切后果均與作者無關！如有侵權，請聯系作者本人進行刪除！

1. 寫在前面

??在數字經濟蓬勃發展的新時代，數據已成為推動社會進步的核心戰略資源，其范疇涵蓋個人信息、商業機密、政府敏感數據等關鍵領域。隨著云計算、大數據、人工智能等前沿技術的深度應用，數據資產的價值呈現指數級增長，與此同時，數據安全風險也日益凸顯，對安全防護體系建設提出了更高要求

2. 指紋檢測

現在很多網站都會通過集成第三方設備指紋（如數美、頂像、京東的風控SDK）或自研系統，從客戶端設備和瀏覽器環境多維度收集特征值，生成唯一指紋后聯動業務風控系統，對后續請求進行動態風險評分。一旦標記為爬蟲行為，就會采取封IP、設備或瀏覽器、限制頁面加載、API訪問權限，甚至彈驗證碼、強制賬號下線等反制措施

而對抗這種防護的核心，就是偽造可信的設備身份。具體來說，可以通過改機工具、使用魔改或指紋瀏覽器，以及編寫JS注入來擦除特征、篡改指紋等方式，偽造出新的設備及瀏覽器環境。通過這些手段，能夠批量生產出大量干凈的設備指紋信息，為爬蟲持續抓取數據提供支持，不過不同廠商的防護強度不同，突破難度也有差異

市面上很多網站會把TLS握手特征和JA3指紋的檢測交給CDN（如 Cloudflare、Akamai等其他盾）處理，利用CDN對已知爬蟲框架、第三方模塊發出的流量進行初步篩選過濾，實現精準識別與攔截

可以根據網站檢測的TLS版本（1.2/1.3），預定義真實瀏覽器的 TLS 模板，讓請求與真實瀏覽器高度一致；也可以收集不同瀏覽器真實的指紋信息形成指紋庫，在此基礎上進行微調。總體來說，此類防護的繞過難度較低

message FingerprintPacket {string session_id = 1;string device_id = 2;int64 ts = 3;repeated KeyValue features = 4;bytes canvas_hash = 5;bytes webgl_hash = 6;
}

3. 行為驗證

不少網站會采購第三方行為驗證碼防護方案（如極驗三代、四代，頂像、數美、易盾，阿里騰訊系）或自研驗證碼系統，與業務風控聯動，對客戶端訪問、請求進行風險攔截，阻斷爬蟲請求

行為驗證碼的突防可以采用自動化和接口協議兩種破解方式。兩種方式的共同難點主要在圖片識別上，這時候可以對接第三方接碼平臺。對于滑塊缺口、單旋轉拼圖，都可以用OpenCV來識別距離（還會結合軌跡｜行為｜指紋來實現動態防護）

其他類型如空間推理、點選驗證等，則需要進行模型訓練。自動化方式還需要解決軌跡拖動特征處理，可以使用經典貝塞爾曲線，再在過程中隨機插值，防止被Bot檢測到。接口協議方式的難點主要集中在圖片還原（圖片亂序或在JS層面有還原邏輯）、接口參數加密、軌跡加密等，其繞過難度不一

絕大部分網站會對核心業務接口進行防護，通過對接口請求參數動態化加密、參數簽名，來抵御請求重放、偽造、篡改

對抗的核心在于逆向分析還原加密與簽名邏輯，或者跳過加密驗簽環節。采用跳過加密驗簽的方式時，首先要找到加密入口，往瀏覽器原生JS中注入WS服務代碼，采用RPC調用的方式拿到加密參數值，提供給爬蟲抓取使用。另一種逆向還原加密的方式，是找到調用的核心加密代碼，梳理出參與加密的入參和使用的加密算法后進行還原，再聯動爬蟲提供驗簽、加密服務，以此偽造請求抓取數據，這種方式的繞過難度也不一致。

某些重點API會集成第三方的WAF服務，通過動態驗證機制對訪問請求進行合法性校驗，要求客戶端完成特定交互驗證，通過后服務端會生成帶有時效性的密文憑證

突防的核心在于模擬完整驗證流程拿到有效憑證。可以通過抓包分析WAF的驗證鏈路，梳理從初始請求到最終獲取憑證的完整API交互流程，在這個過程中拿到服務端下發的多個關鍵參數信息。最后，在提交驗證的接口（一般有加密驗簽）中，通過逆向手段還原加密算法，提交驗證拿到憑證信息。每一次都走這套流程，就能確保WAF認證的憑證永遠在有效期內，實現持續抓取，其繞過難度不一

3. 加固防護

這種防護適用于核心參數加密、請求加簽等任何需要逆向的場景。在 Web 端，會采用禁用控制臺調試、無限 Debugger、核心代碼混淆、VM 化、Webpack 異步且核心防護代碼具備動態更新和自動混淆能力等手段。除此之外，還會通過核心代碼下沉、將核心加密放到 WebAssembly 中，迫使作弊、爬蟲方逆向混淆后的匯編代碼，提升逆向難度。

對抗的核心是從層層防護下破解還原出加密算法。爬蟲仍然可以采用自動化、RPC 的方案進行數據抓取。破解加密簽名參數還可以使用補環境、純算法還原兩種方式。首先都需要解決反調試問題，其次可以選擇對混淆的代碼進行 AST 解混淆以便后續分析；涉及 VMP 的話，還需要投入大量時間進行日志插樁分析，反推并還原加密算法；補環境則只需要將 VMP 代碼扣出來，將加密入口暴露導出，再補全環境即可

4. 鏈路檢測

鏈路檢測是什么？可能很多小伙伴沒有聽說過。這里我們可以把它理解為本次的請求是否遵循了網站預期的訪問路徑（也就是從入口到中間再到最終目前頁面的完整的上下文）目的則是防止爬蟲或濫用者通過直接構造請求去繞過前置頁面、跳過業務交互或觸發關鍵行為（鏈路檢測是行為真實性驗證的重要環節）

導航的路徑上下文是需要滿足短時態、不可偽造、輕量可審計的。下面是一個schema的規則示例:

{"session_id": "sid_abc123","entry_page": "/category/42","entry_ts": 1690000000,"events": [{"type":"resource_load","name":"init.js","ts":1690000001,"hash":"sha256:..."},{"type":"xhr","endpoint":"/api/list","ts":1690000003,"status":200},{"type":"interaction","kind":"click","target":"item_987","ts":1690000005}],"target_page": "/product/987","nonce": "n_456","expires": 1690000025
}

一些站點會通過鏈路檢測機制，對客戶端請求的訪問路徑進行全程追蹤與校驗，防范某些場景下爬蟲直接通過資源 ID（用戶 ID、商品 ID、訂單編號等）跳過前置頁面，直接訪問請求詳情頁掃描的行為

對抗的核心可以考慮從完整的鏈路模擬觸發，構建出合法的鏈路上下文軌跡

5. 風控埋點

做安全防護跟逆向分析的都知道埋點，可以給不知道的小伙伴普及一下。風控埋點 = 客戶端(Web|APP|Native)在請求鏈路中所附帶且用于表征客戶端環境或行為的隱含或顯式字段

它的目標可以是構建客戶端的fingerprint也可以是驗證會話與交互的鏈路還可以是采集行為的特征以及提供惡意客戶端識別的輸入給到風控引擎

一般設定埋在位置包括不限于: HTTP的請求頭內、CK、WS消息、二進制協議、原生的RPC或HTTPS請求內…

按照類別來分的話常見的一些埋點包括了如下所示：

• 靜態類的: UA、分辨率｜時區｜平臺內核的那些信息通常都是很基礎但又必要的一些東西，組合起來就能構成強指紋
• 環境指紋類的: Canvas|WebGL|音頻｜字體｜插件等等指紋、在APP端等價設備ID、廠商｜型號｜ABI｜傳感器等等
• 行為類的: 鼠標的軌跡、滾動與觸摸的節奏、焦點切換與停留時間、交叉的頁面路徑自動化或者腳本往往過于規則化

還有那種埋點的ID跟鏈路事件，比如我們經常會看到在一些頁面請求中，有*_id之類的行為序列，將用于重構會話的路徑與異常檢測

對抗核心邏輯盡量去模擬出真實客戶端完整的執行流程、以及所有可疑的參數防止因埋點參數檢測帶來的風控（單純的完成驗簽與部分偽造不足以繞過一個高質量的風控）

這個過程是耗時且持續性的，需要不斷的分析跟測試最終根據大量的測試數據找到最優方案

6. 游客注冊

目前很多網站為了降低訪問門檻、提升用戶體驗，會開放游客權限機制。用戶無需注冊登錄賬號，僅通過訪問網站即可自動獲得臨時游客身份的Token或Session

這個就很容易被濫用,尤其是被爬蟲或自動化工具批量獲取身份,用于數據抓取、刷單、惡意請求等

但是這類游客身份通常都是有時效性跟某些限制的（重點接口無法訪問）然后也會有一些防護措施，不過一般都不會太難！無非就是限速單一IP或者設備在某時間段內無法生成太多游客（做了指紋的唯一綁定）不規避的話就是異常｜頻繁｜封設備或風控驗證，以及適當的加一個驗簽

對抗的核心測試需要干凈切真實的環境或設備

7. 數據防護

在電商、GOV、影視、本地生活相關客戶端中，為了保護業務數據防止自動化抓取跟協議爬取，平臺通常會對接口響應的數據進行多層加密和混淆，防護的策略通常包括前端解密渲染、字體/樣式加密以及其他不可見的字符映射等手段對明文數據進行防護

常見的一下數據防護手段如下所示：

• 接口響應加密: 服務端將原始數據加密后返回客戶端，客戶端通過JS或Native端的解密后渲染到頁面（常見的加密手段: AES-CBC｜GCM、RSA、HMAC｜SM3、WASM…）
• 前端渲染加密: JS在頁面前端完成解密邏輯并渲染，來阻止單純抓HTML明文數據
• 字體映射與樣式混淆: 使用SFNT｜SVG字體映射或CSS偏移將明文字符替換成編碼碼點或特殊字符，在頁面渲染時再通過字體或樣式將碼點顯示成正確字符（抓到一堆亂碼）

對抗核心則是接口返回的密文分析調試源代碼找到解密算法｜密鑰信息即可還原明文，如果是字體｜CSS加密等方式，需要找到字體文件并下載，再分析編碼規則（一般漢字相關的都會通過Unicode碼點去文件找對應漢字）或使用OCR通用方案識別對字體文件中的文字進行還原

實現原理與流程是：先創建一個白色的背景圖像，再使用ImageDraw在圖像上重新繪制出字符，將圖像轉為RGB格式，最后使用OCR進行識別得到一個關系表。爬蟲通過抓取到的原始數據，通過碼點去表里面檢索，還原被加密的字符，補全并還原出完整的明文數據

8. 賬號權重

目前很多社交媒體，如國外的Meta還有國內的某書某些數據接口都是對賬號有著嚴格的權重校驗。新注冊或者高危的賬號都是無法正常請求訪問

賬號權限重是一套基于歷史行為、認證級別、社交關系、設備和環境等多維特征，為每個賬號分配的“可信度分”。平臺用它決定賬號請求的敏感度

新｜高風險賬號（高頻異常IP、托管的郵箱、異常的設備指紋、臟了的手機號段（一般第三方的那種接碼 ）這些基本默認就是低權重甚至是灰名單（使用的過程中會出現生物驗證或強制下線）

一般會通過多個維度的數據來計算權重:

• 比如注冊的來源或者說渠道: 是否那種虛擬號、第三方、注冊的時間跟速度（批量的特征｜這里不討論底層協議或參數）
• 比如持續的一個活躍度: 日/周/月的登錄次數，會話的長度跟交互的深度（說白了就是有沒有互動的痕跡，這個在以前做Meta的時候深有體會）
• 該賬號的社交圖譜: 這個聽起來是不是有點抽象，這個還真是校驗權重的一個重點標準！該賬號的好友、粉絲、關注這些質量。都是可以做畫像的，一些不合規的業務（一關聯一個準）
• 設備跟地域跨度: 設備的唯一ID、瀏覽器的指紋。IP地址的軌跡路徑（某些社交媒體基于這些觸發一系列的風控驗證，如KYC認證以及認證的方式）

基于上面多維度收集的數據后面就是風控系統工程化的實際操作了，如何去設計權重的分數、如何分配標簽、閾值的判定都是觸發策略鏈的關鍵，包括實時在線決策跟離線標記的這種方案設計

9. 反調阻斷

不管是APP還是Web業務中，大部分平臺不僅對源碼進行了保護還對逆向分析的調試過程做了防護，以此來增加逆向分析的調試成本跟難度

比如下面常見的一些手段:

• 調試的檢測: 檢測調試器、斷點、動態調試的工具、模擬器的特征
• 完整性的一個校驗: 運行時的堆棧或重要的函數是否被Hook
• 蜜罐的放置: 在逆向分析的路徑植入蜜罐以此放分析者浪費大量精力
• 環境的檢測: 檢測沙箱、模擬器、越獄/Root環境

目前大部分的廠商或者平臺對一些重點接口跟數據頁面不光有一次行為驗證，還有二次甚至是更多次的驗證與不同策略的組合驗證，常見的驗證類型:

• 在線行為驗證: 多種驗證碼交叉彈出
• 設備環境驗證: 要求重新校驗設備指紋、發起設備指紋綁定、SMS二次驗證
• 生物/人臉驗證: 針對高風險（跟賬號權重可以捆綁）操作進行強認證

一般它的觸發策略也是分級的，比如低、中、高風險所觸發的驗證場景也都不一樣。基于各種事件觸發（埋點被觸發、蜜罐被點亮了、異地登錄），當然任何的風控系統跟設定的策略目前都是會存在誤殺率的！平臺會對可疑但不確定的流量進行深度檢測（比如說更深度的埋點試探、放探針）收集更多的疊加信息再決策

還有鏈式驗證這個在之前的國外很多平臺第一次驗證或者前幾次都失敗的話就會觸發更高級別的驗證（逐步升級）比如最經典的點選會從6到9再到12再到18格

目前從服務端的角度來講都是可以組合的驗證模塊（可插拔式的組件）風控引擎將會按照設定的策略來組合調用

當然，現在平臺也是會考慮到用戶的。比如一些權重高又或者換一種方式價值高的用戶（這里跟上面的權重還是有聯動的）它會提供快速的恢復甚至是不予驗證（也就是部分用戶的友好化）來減少用戶的流失或投訴

總之歸根結底，疊加驗證往往更大的重心放在防護惡意請求、反作弊對象中。最終都是結合風控系統來實施的