富文本存儲型XSS的模糊測試之道

富文本存儲型XSS的模糊測試之道

憑藉黑吧安全網漏洞報告平臺的公開案例數據，咱們足以管中窺豹，跨站腳本漏洞（Cross-site Script）還是很多企業在業務安全風險排查和修復過程當中須要對抗的「大敵」。
XSS能夠粗分爲反射型XSS和存儲型XSS，固然再往下細分還有DOM XSS, mXSS（突變XSS）, UXSS(瀏覽器內的通用跨站腳本)。其中一部分解決方法較爲簡便，使用htmlspecialchars()對HTML特殊符號作轉義過濾，通過轉義的輸入內容在輸出時便沒法再造成瀏覽器能夠解析的HTML標籤，也就不會造成XSS漏洞。

(圖：htmlspecialchars函數的轉義規則)
但網站作大了，總有一些業務，好比郵件內容編輯、日誌帖子類編輯發佈等功能時，須要受權給用戶自定義連接、改變字體顏色，插入視頻圖片，這時就不得不須要須要引入HTML富文本實現相應功能。以前提到，htmlspecialchars()這樣把全部特殊符號作轉義處理的過濾辦法，這是就英雄無用武之地，由於HTML標籤所有被過濾了，那以前提到的這些用戶能夠自定義功能又該如何實現？
一個問題總有它的解決辦法，因此基於白/黑名單防護思想的富文本內容過濾器應運而生，並很快被應用到了對抗富文本存儲型XSS的前沿。它的任務就是根據內置的正則表達式和一系列規則，自動分析過濾用戶提交的內容，從中分離出合法和被容許的HTML，而後通過層層刪除過濾和解析最終展現到網頁前端用戶界面來。這樣既不影響網站的安全性，也不會妨礙到用戶自定義富文本內容功能的實現。
道高一尺魔高一丈，通過一些前期的手工測試和側面從黑吧安全網公開的漏洞報告中瞭解，大多數網站的富文本過濾器採用「黑名單」的設計思想。這也爲咱們使用模糊測試來自動化挖掘富文本存儲型XSS提供了可能性。

（圖：某國內知名郵箱的富文本過濾器基於「黑名單」設計邏輯）
與此同時，本文的主角，「強制發掘漏洞的利器」-- 模糊測試(Fuzzing Test)，相信各位必定不會陌生。不管是在二進制仍是在WEB端的黑盒測試中都有它立功的身影，從客戶端軟件漏洞的挖掘到WEB端弱口令的爆破，本質上均可以認爲是一種模糊測試。
結合富文本過濾器「黑名單」的實現邏輯，接下來，本文將主要探討這類富文本存儲型跨站腳本的模糊測試之道。將模糊測試這一強大的漏洞挖掘武器經過精細的打磨，挖掘出大量的潛在缺陷。
0x01 找準目標，事半功倍
要進行模糊測試，首先要找準目標。知道目標有哪些地方有富文本編輯器，又有哪些種類，進一步推測其是否基於「黑名單」思想，是否能夠進行自動化的模糊測試。纔可讓咱們接下來要進行的模糊測試，發揮出事半功倍的效果
並非全部容許用戶提交自定義內容的地方，都容許用戶自定義富文本，若是網站已經在後端對全部提交的內容作了htmlspecialchars()的過濾，就意味着全部提交的內容都會被轉義，也就不存在模糊測試的必要了。好比：

黑吧安全網漏洞報告平臺的評論回覆區域，後端的實現邏輯就是不容許用戶傳入富文本內容，對全部用戶輸入的內容作了htmlspecialchars()的過濾。也就是說，若是你傳入相似:

alert(1);    =>  alert(1); 
這時不管你使用何種高大上的XSS Vector，都無濟於事，被轉義之後的內容，沒法對構成XSS跨站腳本。
富文本編輯器也分不少種，好比基於HTML標籤形式的富文本編輯器（Ueditor、Fckeditor），自定義富文本標籤形式（Markdown, UBB），在國內外各大網站都有使用。模糊測試萬變不離其宗，你有了一把鋒利的斧頭，你不管用什麼方式砍柴，本質相同。只是有時候是相似Ueditor的編輯器，在進行模糊測試的時候，可能會更加方便容易。

（圖：百度Ueditor）
0x02 模糊測試框架
就好像寫字以前你必須有一隻筆，砍柴前必須有一把斧子同樣，在開始針對富文本過濾器展開模糊測試以前，你必須得有一個能夠自動生成Payload的模糊測試框架。不管使用JavaScript、PHP、Python仍是更加小衆亦或是高級的語言，模糊測試框架的中心思想就是，經過拼接思想動態生成大量的供模糊測試使用的Payload。對網站富文本編輯器的模糊測試，稍不一樣於對瀏覽器XSS

    

Filter或者是對DOM特性的模糊測試，不過咱們仍是能夠參考一些已經在互聯網上公開的XSS Filter Fuzzer的現成代碼，加以修改，爲我所用，這裏就再也不贅述。
因此，在開始更深一步的模糊測試方案設計以前，請選擇本身駕輕就熟的一種程序設計語言，參考現成的XSS Filter Fuzzer，編寫出一個或簡單或複雜的模糊測試框架。
（圖：基於拼接思想動態生成XSS Fuzzing Test Payload的框架代碼） 0x03 模糊測試模板 有了框架，就比如有了手槍，如今咱們須要給它裝上「子彈」-- 模糊測試模板。一個模糊測試模板的好壞，很大程度上決定了，以後咱們是否可以高效的測試出富文本編輯器中潛在的缺陷，從而發掘出大量的存儲型XSS構造姿式。而在設計本身的模糊測試模板時，主要須要考慮三點：邊界、進制編碼和字符集。 先來講說邊界問題。如下面簡單的HTML代碼爲例： span class=」yyy onmouseover=11111」 style="width:expression(alert(9));">span> 上述HTML標記語言文本傳給後端富文本編輯器的時候，程序會如何過濾和解析？也許是這樣的：首先匹配到，進入其屬性值過濾的邏輯，首先是否含有高危的on開頭的事件屬性，發現存在onmouseover但被」,」包裹，做爲class屬性的屬性值，因此並不存在危險，因而放行；接着分析style屬性，其中有高危關鍵詞」expression()」，又有括弧特殊符號，因此直接清除過濾。 上述過濾流程的實現，很大程度依賴於後端經過正則匹配進行的HTML標籤中的邊界分析。經過對「邊界」的斷定，相似class=」yyyy onmouserover=11111」 的屬性及其值纔會被放行，由於雖然onmouserover=11111雖然是高危的事件屬性，但存在於=」」中，沒有獨立成一個HTML屬性，也就不存在風險。因此在上面的例子中，=」」就是邊界，中的尖括號也是邊界，空格也能夠說成一種邊界。因此，形象一點說，一段HTML代碼的邊界位置頗有多是下面這樣的： [邊界]span[邊界]class=[邊界]yyy[邊界]>[邊界]span[邊界]> 因此若是是相似style="width:expr/*」*/esion(alert(9));"屬性和屬性值呢？程序又該如何肯定邊界？是style="a:expr/*」仍是style="a:expr/*」*/ession(alert(9));"? 當後端富文本過濾程序遇到這樣，略微複雜的選擇題時，若是其後端規則設計的過於簡單，就頗有可能致使把不應過濾的過濾掉，而把非法的內容放行，從而咱們能夠構造出存儲型XSS。打亂HTML邊界，讓後端富文本過濾器陷入選擇窘境，這是咱們設計模糊測試模板的原則之一。有哪些內容可能會致使富文本內容過濾器出現邊界判斷問題？ (1)特殊HTML符號，經過這類明顯的符號，過濾器就能夠到HTML標籤及其屬性，但這些符號錯誤的時候出如今了錯誤的地點，每每會釀成大禍，如: =, 」, ’, :, ;, >, (2)過濾器會過濾刪除的內容，咱們在邊界填充下面這些元素，過濾器盲目刪除，頗有可能致使本來無害的屬性值，掙脫牢籠，成爲惡意的屬性和屬性值，如： expression, alert, confirm, prompt, , (3)不可打印字符，如： \t、\r、\n、\0等不可打印字符 綜上，如今咱們已經能夠用Fuzzer生成一個下面這樣的Payload。幸運的話，或許已經能夠繞過一些後端邏輯簡單的富文本過濾器了，示例以下： span/class=/yyyy onmouseover=11111/style="a:exp/*」>*/resion(1);">span> 固然，除了邊界區分問題，富文本過濾器面對着另外兩個勁敵，特殊的進制字符編碼和千奇百怪的字符集。 咱們先來講說字符編碼，相似\x22,\40,"等一系列進制編碼，直接看成文本內容傳遞給後端富文本過濾器，若是處理的辦法？解密後過濾？直接輸出？經驗告訴咱們，很多過濾器在處理相似特殊的進制編碼時，每每會在進制編碼的特殊HTML符號面前摔我的仰馬翻。因而，像下面這樣一段看似無害化的Payload，在富文本過濾器自做聰明的解密事後，變成了一段跨站腳本： 前：span class=」yyy "onmouseover=alert(1);//」>span>  => 後：span class=」yyy「 onmouseover=alert(1);//」>span> 接下來，咱們再來講說千奇百怪的字符集，很多富文本編輯器在處理相似「㊗」的unicode字符時，會將字符轉化成標籤，因此在mramydnei報告的一個騰訊郵箱存儲型XSS中，一段無害的Payload逆襲成了有害的跨站腳本： 前：style x="㊗" y="Fuzzitup {}*{xss:expression(alert(document.domain))}">  => 後：style x=" https:="" res.mail.qq.com="" zh_cn="" htmledition="" images="" emoji32="" 3297.png"="">" y="Fuzzitup {}*{xss 上一頁        :expression(alert(document.domain))}">style> 0x04 模糊測試實戰 正所謂「磨刀不誤砍柴工」，在進行模糊測試實戰以前，我建議，對富文本過濾器的大改過濾規則和實現原理手動測試一番，瞭解哪些HTML標籤容許被使用，有哪些關鍵詞出現就會被刪除，又有哪些Payload會觸發網站存在的WAF，在以後的測試中，針對目標網站「個性化」的修改模糊測試模板。 講到這裏，相信你已經大概瞭解富文本跨站腳本模糊測試了，不過模糊測試的威力究竟如何呢？咱們用實例來作論證： 網易有道雲筆記存儲型XSS [進制編碼處理缺陷] XSS利用技巧（自動觸發/全部瀏覽器通用） 小米論壇存儲型XSS [進制編碼處理缺陷] 新浪郵箱存儲型XSS [邊界斷定缺陷] QQ郵箱存儲型XSS [字符集處理缺陷] WooYun: 騰訊郵箱郵件正文存儲型漏洞 "> WooYun: 騰訊郵箱郵件正文存儲型漏洞 QQ郵箱存儲型 XSS [字符集處理缺陷] 0x05 寫在最後 模糊測試只是自動化強制發現漏洞的一個重要手段，就像自動化漏洞掃描器同樣。咱們並不能徹底依靠它，在測試過程當中，對過濾器結果進行適時的分析，對模糊測試模板作出合理的改進，不只能提升模糊測試的效率，還可以幫助咱們挖掘到更多潛在的設計缺陷。畢竟，機器終究是「死板」的，而人是「靈活」的。 富文本跨站腳本測試之道，就是細緻的模糊測試結果分析，加上對模糊測試模板的不斷打磨，人與機器的結合，纔會打造出一把真正的「神器」。   上一頁