一、背景介紹

在業務安全領域，滑動驗證碼已經是國內繼，傳統字符型驗證碼之後的標配。衆所周知，打碼平臺和機器學習這兩種繞過驗證碼的方式，已經是攻擊者很主流的思路，不再闡述。本文介紹的是一個冷門的繞過思路和防禦方案。這些積累，均來自於實戰之中，希望有用。

二、 黑產攻擊者

知己知彼，百戰不殆。

如果不清楚攻擊者的手段，又如何能制定防禦方案？

滑動驗證碼繞過思路

漏洞名字： session 參數 重複校驗漏洞

思路介紹：

此思路來源於一次對黑產路徑的溯源復現，由於每次拖動滑塊後，會發送一個Request請求數據包到服務器，服務器會驗證這個Request請求數據包裏攜帶的位移參數，來判斷是否是拖動滑塊到了正確的缺口位置。而服務器接收的數據包有很多，除了你發送的，也還會有其他人發送的請求，所以需要一個session參數來作爲標識。本文中的”rid”值就是一個session標識。

其中”rid”值是加引號的，因爲它只是一個參數。針對不同的滑動驗證碼廠商，可能參數命名不一樣。

漏洞詳情：

在用戶客戶端完成一次正確的驗證碼滑動後，發送到服務器的session參數，會在服務器後端，默認隱含生成一個有效時間和一個有效次數的值。前提條件是正確的滑動。想想這裏會不會存在問題?

曾在黑盒測試中發現，有的滑動驗證碼廠商的後端邏輯設計存在缺陷，一個session參數的有效時間是10分鐘，有效使用次數是5次。那麼如何利用呢？這是我在風控後臺的真實業務環境下，挖掘到的一條黑產繞過滑動驗證碼的手法。

思路剖析：

首先，觸發滑動驗證機制，如下圖類似。

接着，滑動滑塊到正確缺口位置，然後抓包。

分析數據包，尋找session參數。通過測試找到”rid”值爲session參數。

這裏再強調一下，不同的廠商開發的代碼，可能對session參數命名不一樣。比如下圖，”sessionId”值是另一家廠商的session參數，需要我們去分析判斷。

每次滑動正確位移後，使用Brupsuite或者其它中間人代理工具，抓包提取數據包裏的session參數（”rid”值），保存到本地。        

因爲服務器後端默認隱含對我們本地保存的session參數有一個有效時間和有效次數，所以我們不需要再去滑動驗證碼，直接在session的有效期內發送Request請求數據包到服務器即可驗證成功！

上述操作，我用python編寫了一個小工具使其流程化。全自動化過程：調用打碼平臺滑動驗證碼滑塊到正確位置，使用python的mitmproxy庫配合正則提取rid，並寫入保存到本地rid.txt。

最後黑產在實際批量註冊，薅羊毛或刷贊過程中，遇到觸發的滑動驗證碼機制，只要session在有效期內，只需使用python讀取本地的rid.txt內容，調用requests庫發送請求數據包，即可繞過滑動驗證碼。

至此，滑動驗證碼繞過思路剖析完成。

滑動驗證碼js接口XSS攻擊:

衆所周知的跨站腳本攻擊—XSS，攻擊手法可能很平常，但把常用的攻擊手法用在一個不被人注意的地方，有時候會給你意想不到的效果。

在某次實戰中，對一個安全公司的真實後臺登錄頁面做黑盒測試。

首先，給到的只有一個這種後臺登錄頁面。

對常規的地方進行一番測試後，並沒有發現什麼脆弱缺陷。既是一家安全公司，安全防護做的比較高，也是意料之中的事。在屏幕前發了很久的呆，沒有思路的時候，喜歡倒退，會回到滲透測試最本質的起點，信息收集。

因爲這家公司做的是業務安全，瞭解到這個後臺是一個風控數據監測的登錄後臺。

風控面對的業務場景有：註冊、登錄、瀏覽，支付，活動等。

面對的威脅有：惡意爬蟲、批量註冊、薅羊毛、盜號撞庫等。

風控策略有：限制註冊登錄頻率、惡意IP識別、驗證碼等。

【惡意/正常行爲】——【風控策略】——【業務場景】，風控在其中扮演者中間人的角色，無論是一個正常用戶的行爲還是羣控設備的惡意行爲，風控一方面會使用策略進行過濾行爲，另一方面會將惡意/正常行爲會被記錄到日誌中，進而在後臺展示。

至此，信息收集完畢，我們整理一下思路。

我們先看一下手裏拿到的測試頁面，再對比分析一下上面那段信息。

我們發現這個登錄頁，是有滑動驗證碼的。而對比上面的信息，我將紅色框圈出來的文字，構建了一個我的漏洞測試想法。如果我能控制滑動驗證碼的輸入，那在後臺的輸出也可能將是可控的。紅色框圈出的最後四個字，“後臺展示”，第一反應就是用XSS攻擊手法再合適不過了。

開始行動

首先，找到獲取滑動驗證碼的js接口

分析接口參數

找到以下參數：

channel,appId,orgaization,lang,data,sdkver,callback,model,reversion

黑盒XSS——FUZZ

刷新驗證碼，截斷，抓包。

蠻力碰撞，直接把所有的參數的值替換成XSS payload，但這樣往往容易失敗，因爲有些參數是硬編碼，一旦更改，服務器返回的respnse就會直接顯示reject拒絕。

捨近求遠，9個參數，抓9次包，分別替換參數值成XSS payload，最後，幾分鐘後，成功打到了cookie。

(因爲XSS平臺更新，當時的記錄未保存)

因爲是黑盒測試，在漏洞修復後，內部人員把後臺觸發漏洞的位置告訴了我。

下面這張圖是，風控後臺的滑動驗證碼記錄的行爲信息展示欄，未修復之前這裏有一列language的值，就是參數裏的”lang”，而插入的XSS payload也就會出現在這個位置。

由於開發人員未考慮到這個隱祕的js接口，所以未做過濾防護，且未申明http only，導致XSS payload可以順利執行。

最後，在黑盒測試盲打XSS中，很大一部分靠運氣。但使用極限語句再配合一個超短域名的XSS平臺，會增加成功率。

風控防禦方

滑動驗證碼可能會部署在：註冊、登錄、反爬、支付等場景當中，而黑產繞過滑動驗證碼的技術會有很多種，但凡只要有一種是當前風控策略未考慮的情況，就可能會造成比較嚴重的損失。

攻擊手法總結

從黑產/攻擊者的角度，針對滑動驗證碼，我們介紹了一種繞過的思路：session參數重複校驗漏洞，一種攻擊的手法：JS接口的XSS攻擊。

那麼，從風控/防禦方的角度，我們如何制定防守方案呢？才疏學淺，不敢無稽之談，只能把平時實戰之中碰到的問題，記錄下來，希望有用。

被動防守——針對攻擊者

這裏沒什麼特色，既然是被動防守，自然是要避免亡羊補牢。針對諸如XSS等OWASP TOP漏洞，不能依賴開發的細心。除了在業務上線之前，內部測試和攻防測試；還可以在在業務上線之後，託管類似國外Hackone平臺的國內賞金平臺，或自運營SRC。當然，結合考慮預算成本。

主動出擊——針對灰黑產

主動出擊，針對的是利用滑動驗證碼，來精準識別灰黑產。

在上一篇文章實戰筆記之X廠滑動驗證碼漏洞挖掘裏最後一節，提到了多缺口、滑塊多樣化的方案。

在一次滑動驗證碼更新升級過程中，發現了一個新思路。

原始過程：在用戶完成一次驗證碼滑動後，將request請求數據包發送給服務器。

升級方案：在服務器後端升級滑動驗證碼的js代碼，使每一個滑動驗證碼都在用戶客戶端生成一個或多個隨機參數，這些隨機參數需要跟隨request請求發送到服務器進行一個簡單邏輯驗證。重點在於：正常用戶只有通過滑動滑塊發送的request數據包才一定是攜帶隨機參數的，但並不強制要求發送的request請求攜帶這些隨機參數。

精準識別：因爲核心圈的黑產下放的工具，都是通過直接通過發送request請求數據包來進行批量註冊、刷量刷贊和惡意爬蟲等行爲。稱之爲：“協議刷”或“打接口”，這種方式效率極高。加上利益化的原因，黑產不會去在乎過程，只在乎是否結果能成功。

升級的方案：只有通過正常滑動滑塊，才能發送攜帶隨機參數的request數據包發到服務器。

舊方案：通過以前的舊接口直接發送不攜帶隨機參數的request數據包到服務器也可以通過驗證。

在無聲無息升級後，兩種方案並行運行，那麼拐點就到來了。

是不是就意味着舊方案的驗證碼接口過來的ip，sdk，captcha_flag等數據一定都是源於黑產池；而升級方案的驗證碼接口過來的ip，sdk，captcha_flag等數據不說百分百，也絕大部分都是來自正常用戶羣體。這就悄然無聲的就達到了精準識別灰黑產的目的。

持續化：在被黑產發現後，就需要做持續化更新的對抗了。

還是那句，攻防本身就是一場不公平的戰鬥，或許只要能大大增加黑產攻擊者的成本，就是有效果的防守。

三、總結

以上理論，皆爲實戰總結。希望有用。

如果沒有，我想下篇或許會有。

*本文作者：N10th九號，轉載請註明來自FreeBuf.COM