續上篇，實戰筆記之X廠滑動驗證碼漏洞挖掘
關鍵字：接口XSS、重複校驗、灰黑産識别
閱讀簡介：第二節，繞過和攻擊
第三節：風控防禦
一、背景介紹
在業務安全領域，滑動驗證碼已經是國内繼，傳統字元型驗證碼之後的标配。衆所周知，打碼平台和機器學習這兩種繞過驗證碼的方式，已經是攻擊者很主流的思路，不再闡述。冷滲透介紹的是一個冷門的繞過思路和防禦方案。這些積累，均來自于實戰之中，希望有用。
二、黑産攻擊者
知己知彼，百戰不殆。
如果不清楚攻擊者的手段，又如何能制定防禦方案？
1. 滑動驗證碼繞過思路
漏洞名字：session參數重複校驗漏洞
思路介紹：
此思路來源于一次對黑産路徑的溯源複現，由于每次拖動滑塊後，會發送一個Request請求資料包到伺服器，伺服器會驗證這個Request請求資料包裡攜帶的位移參數，來判斷是否是拖動滑塊到了正确的缺口位置。而伺服器接收的資料包有很多，除了你發送的，也還會有其他人發送的請求，是以需要一個session參數來作為辨別。本文中的"rid"值就是一個session辨別。
其中"rid"值是加引号的，因為它隻是一個參數。針對不同的滑動驗證碼廠商，可能參數命名不一樣。
漏洞詳情：
在使用者用戶端完成一次正确的驗證碼滑動後，發送到伺服器的session參數，會在伺服器後端，預設隐含生成一個有效時間和一個有效次數的值。前提條件是正确的滑動。想想這裡會不會存在問題？
曾在黑盒測試中發現，有的滑動驗證碼廠商的後端邏輯設計存在缺陷，一個session參數的有效時間是10分鐘，有效使用次數是5次。那麼如何利用呢？這是我在風控背景的真實業務環境下，挖掘到的一條黑産繞過滑動驗證碼的手法。
思路剖析：
①首先，觸發滑動驗證機制，如下圖類似。
②接着，滑動滑塊到正确缺口位置，然後抓包。
分析資料包，尋找session參數。通過測試找到"rid"值為session參數。
這裡再強調一下，不同的廠商開發的代碼，可能對session參數命名不一樣。比如下圖，"sessionId?imageView2/2/w/1620"值是另一家廠商的session參數，需要我們去分析判斷。
③每次滑動正确位移後，使用Brupsuite或者其它中間人代理工具，抓包提取資料包裡的session參數（"rid?imageView2/2/w/1620"值），儲存到本地。
因為伺服器後端預設隐含對我們本地儲存的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）持續化：在被黑産發現後，就需要做持續化更新的對抗了。
還是那句，攻防本身就是一場不公平的戰鬥，或許隻要能大大增加黑産攻擊者的成本，就是有效果的防守。
三、總結
以上理論，皆為實戰總結。希望有用。
如果沒有，我想下篇或許會有。
技術研究總是孤獨的，
邊緣化的東西更是如此。
一個隻專注冷門滲透技巧，
研究灰黑産的暗侍衛。
———冷滲透
文由微信公衆号:冷滲透