一、事件背景
A域名接入了動態防護(Bot 防護、反爬蟲機制),同時第三方業務B域名通過內嵌iframe的方式調用了A域名下的一個鏈接。
二、動態防護介紹:
動態防護(也稱為 Bot 防護、反爬蟲機制)是網站為了防止自動化程序(如爬蟲、惡意腳本)大規模訪問而采取的一種安全措施。通過先返回一段 JS 代碼到客戶端執行,然后生成 Cookie就是其中一種非常典型的 客戶端驗證機制。
🔍 原理詳解:為什么需要執行 JS 來生成 Cookie?
🧠 核心思想:
服務器通過檢測客戶端是否具備完整的瀏覽器環境來判斷是否為真人或自動化工具(如爬蟲、Selenium 等)。如果直接請求頁面,沒有執行 JS,就說明不是真正的瀏覽器行為,可能是機器。
? 典型流程如下:
首次請求
- 客戶端(比如瀏覽器或爬蟲)向服務器發送 HTTP 請求。
- 服務器識別到這不是一個具有完整 JavaScript 執行能力的瀏覽器(比如沒有 session 或者 cookie),于是不返回真實內容。
返回一段 JS 代碼
- 服務器返回一個 HTML 頁面,里面包含一小段 JavaScript 腳本,這段腳本通常會:
- 計算一些隨機值
- 設置?
document.cookie
- 或者重定向到某個帶 token 的 URL
- 服務器返回一個 HTML 頁面,里面包含一小段 JavaScript 腳本,這段腳本通常會:
JS 在瀏覽器中執行
- 瀏覽器執行這段 JS,生成特定的 Cookie(例如?
_cf_bm
,?__cfduid
,?challenge
?類似的 cookie) - 然后自動發起一個新的請求(可能通過?
location.href
?或?form.submit()
)
- 瀏覽器執行這段 JS,生成特定的 Cookie(例如?
第二次請求
- 新請求帶上剛才生成的 Cookie,服務器驗證這個 Cookie 是否合法。
- 如果合法,則放行,返回正常網頁內容;否則繼續攔截。
🧪 示例:Cloudflare 的挑戰機制
以 Cloudflare 的典型 bot 防護為例:
- 當你第一次訪問被保護的網站時,它會返回如下內容:
<html>
<head><title>請等待...</title></head>
<body><script>// 這里是一段混淆過的 JS 代碼var s,t,o,p,b,r,e,a,f,i,n, c = document;// ... 一系列復雜計算 ...document.cookie = "cf_clearance=xxx; path=/; expires=...; Secure";location.reload(); // 刷新頁面</script>
</body>
</html>
- 這個 JS 會設置一個叫?
cf_clearance
?的 Cookie,它是基于時間戳、隨機數和哈希算法生成的。 - 下次請求帶上這個 Cookie,服務器驗證通過后才允許訪問真實內容。
?? 對爬蟲的影響
這種機制對傳統爬蟲(如 requests、urllib)來說是一個重大障礙,因為它們無法執行 JavaScript,也就無法生成所需的 Cookie。
解決方案包括:
方法 | 描述 | 優缺點 |
---|---|---|
使用 Selenium / Playwright | 模擬真實瀏覽器 | 可繞過大多數 JS 驗證,但資源消耗大 |
使用 Puppeteer | Node.js 控制 Chrome | 功能強大,但速度慢 |
逆向工程 JS 邏輯 | 手動提取 JS 生成 Cookie 的邏輯,用 Python 實現 | 效率高,但開發成本高且容易失效 |
使用第三方服務 | 如 Anti-Captcha、2Captcha、ScraperAPI 等 | 成本較高,但省事 |
🛡? 舉個小例子(簡化版原理)
假設服務器下發以下 JS:
let t = Date.now();
let hash = btoa(t + Math.random());
document.cookie = `my_challenge=${hash}; path=/`;
location.href = '/real-content';
這段 JS 的作用是:
- 獲取當前時間戳
- 生成一個 base64 編碼的 hash
- 設置成 Cookie
- 自動跳轉到真實頁面
服務器收到 /real-content
請求時,檢查是否有這個 Cookie,并驗證其格式、時效等,如果沒問題就放行。
? 總結:為什么要執行 JS 來生成 Cookie?
目的 | 說明 |
---|---|
區分瀏覽器和爬蟲 | 瀏覽器能執行 JS,爬蟲不能(除非模擬) |
防止濫用 | 減少機器人刷接口、刷票、DDoS 攻擊等行為 |
增加爬取成本 | 增加攻擊者的逆向難度和維護成本 |
提升安全性 | 可結合瀏覽器指紋、TLS 指紋等多維度識別 |
三、業務適配問題
如果 <iframe>
加載的是不同源的內容,瀏覽器會實施 同源策略,阻止以下行為:
- 父頁面訪問?
<iframe>
?的 DOM 或執行其中的 JavaScript。 <iframe>
?訪問或修改父頁面的內容。
這就導致第三方域名下內嵌的iframe 無法加載動態防護的JS完成檢驗。
四、解決方案
調整動態防護策略
對來自特定來源的請求放寬限制,如加白調用的IP(IP是固定的)、加白被第三方域名調用的url、放行調用請求的某個特征(如UA、refer 等)。