以下文章來源於冷滲透 ，作者九號(N10th)
續上篇，實戰筆記之X廠滑動驗證碼漏洞挖掘
一、背景介紹
在業務安全領域，滑動驗證碼已經是國內繼，傳統字符型驗證碼之後的標配。眾所周知，打碼平臺和機器學習這兩種繞過驗證碼的方式，已經是攻擊者很主流的思路，不再闡述。冷滲透介紹的是一個冷門的繞過思路和防禦方案。這些積累，均來自於實戰之中，希望有用。
二、黑產攻擊者
知己知彼，百戰不殆。
如果不清楚攻擊者的手段，又如何能制定防禦方案？
1. 滑動驗證碼繞過思路
漏洞名字：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庫發送請求數據包，即可繞過滑動驗證碼。
至此，滑動驗證碼繞過思路剖析完成。
2. 滑動驗證碼js接口XSS攻擊
眾所周知的跨站腳本攻擊—XSS，攻擊手法可能很平常，但把常用的攻擊手法用在一個不被人注意的地方，有時候會給你意想不到的效果。
在某次實戰中，對一個安全公司的真實後臺登錄頁面做黑盒測試。
①首先，給到的只有一個這種後臺登錄頁面。
②對常規的地方進行一番測試後，並沒有發現什麼脆弱缺陷。既是一家安全公司，安全防護做的比較高，也是意料之中的事。在屏幕前發了很久的呆，沒有思路的時候，喜歡倒退，會回到滲透測試最本質的起點，信息收集。
③因為這家公司做的是業務安全，瞭解到這個後臺是一個風控數據監測的登錄後臺。
風控面對的業務場景有：註冊、登錄、瀏覽，支付，活動等。
面對的威脅有：惡意爬蟲、批量註冊、薅羊毛、盜號撞庫等。
風控策略有：限制註冊登錄頻率、惡意IP識別、驗證碼等。
【惡意/正常行為】——【風控策略】——【業務場景】，風控在其中扮演者中間人的角色，無論是一個正常用戶的行為還是群控設備的惡意行為，風控一方面會使用策略進行過濾行為，另一方面會將惡意/正常行為會被記錄到日誌中，進而在後臺展示。
④至此，信息收集完畢，我們整理一下思路。
我們先看一下手裡拿到的測試頁面，再對比分析一下上面那段信息。
⑤我們發現這個登錄頁，是有滑動驗證碼的。而對比上面的信息，我將紅色框圈出來的文字，構建了一個我的漏洞測試想法。如果我能控制滑動驗證碼的輸入，那在後臺的輸出也可能將是可控的。紅色框圈出的最後四個字，“後臺展示”，第一反應就是用XSS攻擊手法再合適不過了。
開始行動
a. 首先，找到獲取滑動驗證碼的js接口
b. 分析接口參數
找到以下參數：
channel,appId,orgaization,lang,data,sdkver,callback,model,reversion
c. 黑盒XSS——FUZZ
刷新驗證碼，截斷，抓包。
（1）蠻力碰撞，直接把所有的參數的值替換成XSS payload，但這樣往往容易失敗，因為有些參數是硬編碼，一旦更改，服務器返回的respnse就會直接顯示reject拒絕。
（2）捨近求遠，9個參數，抓9次包，分別替換參數值成XSS payload，最後，幾分鐘後，成功打到了cookie。
(因為XSS平臺更新，當時的記錄未保存)
（3）因為是黑盒測試，在漏洞修復後，內部人員把後臺觸發漏洞的位置告訴了我。
下面這張圖是，風控後臺的滑動驗證碼記錄的行為信息展示欄，未修復之前這裡有一列language的值，就是參數裡的"lang"，而插入的XSS payload也就會出現在這個位置。
由於開發人員未考慮到這個隱秘的js接口，所以未做過濾防護，且未申明http only，導致XSS payload可以順利執行。
（4）最後，在黑盒測試盲打XSS中，很大一部分靠運氣。但saya師傅告訴我，使用極限語句再配合一個超短域名的XSS平臺，會增加成功率。
二、風控防禦方
滑動驗證碼可能會部署在：註冊、登錄、反爬、支付等場景當中，而黑產繞過滑動驗證碼的技術會有很多種，但凡只要有一種是當前風控策略未考慮的情況，就可能會造成比較嚴重的損失。
1. 攻擊手法總結
從黑產/攻擊者的角度，針對滑動驗證碼，我們介紹了一種繞過的思路：
session參數重複校驗漏洞，一種攻擊的手法：JS接口的XSS攻擊。
那麼，從風控/防禦方的角度，我們如何制定防守方案呢？九號才疏學淺，不敢無稽之談，只能把平時實戰之中碰到的問題，記錄下來，希望有用。
2. 被動防守——針對攻擊者
這裡沒什麼特色，既然是被動防守，自然是要避免亡羊補牢。針對諸如XSS等OWASP TOP漏洞，不能依賴開發的細心。除了在業務上線之前，內部測試和攻防測試；還可以在在業務上線之後，託管類似國外Hackone平臺的國內賞金平臺，或自運營SRC。當然，結合考慮預算成本。
3. 主動出擊——針對灰黑產
主動出擊，針對的是利用滑動驗證碼，來精準識別灰黑產。
①在上一篇文章實戰筆記之X廠滑動驗證碼漏洞挖掘裡最後一節，提到了多缺口、滑塊多樣化的方案。
②在一次滑動驗證碼更新升級過程中，發現了一個新思路。
（1）原始過程：在用戶完成一次驗證碼滑動後，將request請求數據包發送給服務器。
（2）升級方案：在服務器後端升級滑動驗證碼的js代碼，使每一個滑動驗證碼都在用戶客戶端生成一個或多個隨機參數，這些隨機參數需要跟隨request請求發送到服務器進行一個簡單邏輯驗證。重點在於：正常用戶只有通過滑動滑塊發送的request數據包才一定是攜帶隨機參數的，但並不強制要求發送的request請求攜帶這些隨機參數。
（3）精準識別：因為核心圈的黑產下放的工具，都是通過直接通過發送request請求數據包來進行批量註冊、刷量刷贊和惡意爬蟲等行為。稱之為：“協議刷”或“打接口”，這種方式效率極高。加上利益化的原因，黑產不會去在乎過程，只在乎是否結果能成功。
升級的方案：只有通過正常滑動滑塊，才能發送攜帶隨機參數的request數據包發到服務器。
舊方案：通過以前的舊接口直接發送不攜帶隨機參數的request數據包到服務器也可以通過驗證。
在無聲無息升級後，兩種方案並行運行，那麼拐點就到來了。
是不是就意味著舊方案的驗證碼接口過來的ip，sdk，captcha_flag等數據一定都是源於黑產池；而升級方案的驗證碼接口過來的ip，sdk，captcha_flag等數據不說百分百，也絕大部分都是來自正常用戶群體。這就悄然無聲的就達到了精準識別灰黑產的目的。
（4）持續化：在被黑產發現後，就需要做持續化更新的對抗了。
還是那句，攻防本身就是一場不公平的戰鬥，或許只要能大大增加黑產攻擊者的成本，就是有效果的防守。
三、總結
以上理論，皆為實戰總結。希望有用。
閱讀更多 白帽子 的文章
