XSS 攻擊簡單、危害大

Web 應用的研發人員對用戶的輸入輸出若不加以嚴格控制,會導致產生 XSS 漏洞。XSS 漏洞的利用方式也非常簡單,普通的攻擊者通過 XSS 漏洞發起攻擊可以獲取用戶(甚至是管理員)的訪問權限進行敏感操作。

傳統掃描 XSS 的方式

多年來,XSS 氾濫成災,在 OWASP TOP 10 中的地位居高不下,安全研究者提出了許多 XSS 漏洞的掃描方式,我們來回顧一下:

第一代 XSS 漏洞掃描

安全工作者通常喜歡用彈框(js 中的 alert 函數)來證明一個頁面是否存在 XSS 漏洞,因此也誕生了一批流傳非常廣泛的 XSS Payload:

<script>alert(/xss/)</script>

<body onload=alert(/xss/)>

<img src=# onerror=alert(/xss/)>

帶着以上 Payload 進行訪問,如果看到一個類似這樣的彈框,說明漏洞真實存在。

第一代 XSS 漏洞掃描工具就是利用這個思路,在工具內部集成了大量 XSS Payload,在掃描時逐個進行嘗試,自動將參數替換爲 Payload,如果服務端的響應中包含相同的字符串就認爲發現了 XSS 漏洞。

第一代 XSS 漏洞掃描工具填補了歷史的空白,可以發現了大量初級 XSS 漏洞,但是隨着 XSS 攻擊的發展,衍生出了新的 XSS 攻擊手段,此類工具也完成了它的歷史使命,它解決不了的問題包括:

原始 Payload 無法靈活變形,無法應對需要 DOM 渲染才能觸發的 XSS 漏洞輸出點的部位不一定可執行,會造成誤報服務端有過濾邏輯時返回的字符串與原始 Payload 有差異,可能導致無法匹配響應中被過濾後的 Payload如果 Content-Type 不是 text/html,即使 Payload 能夠輸出也無法執行服務端有防護時,許多 Payload 會導致請求直接被攔截等等第二代 XSS 漏洞掃描

當大量初級 XSS 漏洞被解決之後,攻擊者對於 XSS 漏洞的利用方式也逐漸成熟,安全建設對於 XSS 漏洞的目標變成了“全面解決 XSS 攻擊”。這個時期出現了許多思路新穎的 XSS 漏洞掃描工具,這些工具能覆蓋許多第二代 XSS 漏洞掃描工具無法發現的問題,在當初的年代堪稱神器,但是依然存在着或多或少的問題,因此始終無法推廣到整個行業,成爲可量產的 XSS 掃描基礎算法。

第二代掃描中表現最出色的方式是調用真實瀏覽器來輔助判斷,hook 瀏覽器的基礎函數,累積更加龐大的 Payload 規則庫,覆蓋更多的輸入輸出場景,使瀏覽器告訴掃描器漏洞是否可實際被利用。這種掃描思路的特點是:

幾乎沒有誤報可以發現部分 DOM 型 XSS會發送大量 HTTP 請求每次請求都需要調用瀏覽器進行渲染,因此掃描速度奇慢無比掃描效果與 Payload 的覆蓋量息息相關

無論是第一代還是第二代 XSS 漏洞掃描,都缺少了對於上下文的理解以及對於場景的分析,無法擺脫其 Fuzz 的本質,優化的方向也停留在“如何使猜測的結果更靠近真實結果”,而不是“如何正向推理得出正確答案”,因此依然由於多場景是無法解決的,問題在於:

Web 業務複雜,輸出點的類型非常多,payload 不可能覆蓋所有的情況依然無法解決 WAF 會攔截敏感 payload 的問題誤報漏洞的問題依然嚴重

那麼有沒有一種可以快速、深度、精準的 XSS 漏洞探測方法呢?

從歷史的行程來看,XSS 漏洞掃描需要解決根本的問題在於對於輸入輸出場景的識別,對於不同瀏覽器渲染方式的理解,以及對於服務器處理方式的靈活應對。

長亭洞鑑使用了一種全新的 XSS 漏洞分析算法,脫離了傳統的對於 Payload 規則庫的依賴,無需大量發送 HTTP 請求即可完成頁面分析,定位存在的 XSS 漏洞,並智能化生成最終的複測 Payload。

看一個簡單的例子,有以下 URL:

http://xx.chaitin.cn/test?p=866f268a344ba71fa4b0

用戶訪問後會得到如下的返回:

<html><body><a href=”./news/866f268a344ba71fa4b0/”><img src=”./xxx.png”></a></body></html>

這是一段可能存在 XSS 的代碼,業務將用戶輸入的 p 參數輸出到了 a 標籤的 href 屬性中。熟悉 XSS 的同學無需多想即可編寫如下驗證該漏洞的 Payload。

“><script>alert</script>

自動化掃描工具只要覆蓋這個 Payload 即可驗證如上的漏洞。但是這個 Payload 真的能工作麼?其實還需要考慮其他因素:

    參數是否會被服務器編碼或解碼參數中是否允許存在空格,是否有長度限制會不會有 WAF 攔截 script 或 alert 等關鍵字( 和 ) 有沒有可能被過濾或轉義” 和 ‘ 有沒有可能被過濾或轉義< 和 > 有沒有可能被過濾或轉義有沒有其他可以利用的屬性,是否可以使用 onXXX 事件,有沒有可能被過濾或轉義有沒有 CSP 策略等等

如果是傳統自動化黑盒掃描器,包含如上文“無需多想”的 Payload 已屬不易,以上意外因素只要存在一點就可以使掃描鎩羽而歸,更難想想需要累積並嘗試多少 Payload 才能實際驗證一個這樣的 XSS 漏洞。

想要精細化發現 XSS 漏洞,必須站在理解 DOM 結構的基礎上,長亭洞鑑實現了兼容各種瀏覽器標準的 DOM 解析器,使可分析的參數輸出點可以覆蓋到包括但不限於以下範圍:

輸出在標籤外部輸出在 HTML 註釋中輸出在標籤的屬性內部輸出在標籤的屬性外部輸出在標籤的事件內部輸出在地址的部位,如 a/href、form/action、iframe/src 等輸出在標籤的 style 屬性內部輸出在 style 標籤內輸出在 script 標籤內的字符串中輸出在 script 標籤內的註釋中輸出在特殊標籤內部輸出在特殊標籤的特殊屬性內部

除此之外,自動化工具還需要理解參數傳遞方式與常見編碼方式,考慮如何自動化識別服務器對參數的編碼方式,如何定位 Payload 中的敏感字符,並對 Payload 關鍵部分進行編碼。洞鑑內置的編碼探測算法與自動編碼算法可以解決該問題,可覆蓋的編碼類型包括但不限於:

HTML EntityHTML CodeHTML Hex CodeURL Encodejs string literalGBKUTF-7Base64

對於上文提到的漏洞,長亭洞鑑的發現過程會更加智能化,在理解業務的基礎上進行深度分析,定位漏洞,並自動生成 Payload,簡單模擬一遍,可以將發現過程簡單理解如下:

    訪問原始頁面,判斷輸入是否會出現在頁面上結論:參數 p 的內容會出現在頁面上根據 HTML 的語義建立 DOM 結構,判斷輸出在 DOM 中的位置結論:輸出位於 a 標籤的 href 屬性中輸出是否需要衝突破閉合結論:href 屬性在雙引號內,因此需要使用 ” 突破閉合,也可以進一步使用 > 突破標籤閉合是否能插入可執行的 js結論:不存在其他干擾標籤,可以使用 ” 突破閉合後插入標籤事件或插入新的標籤基本確定 XSS 漏洞存在,開始嘗試自動生成 Payload,生成 Payload 時需要考慮

洞鑑掃描截圖如下:

    正在掃描的任務詳情部分截取
精細化掃描 XSS 漏洞-智能化場景分析

2. XSS 漏洞詳情部分截取

精細化掃描 XSS 漏洞-智能化場景分析總結

傳統的 XSS 掃描簡單粗暴,無法實現“全面發現 XSS 漏洞”的目標。

長亭洞鑑集成了基於智能化場景分析算法的掃描引擎,可以精確定位參數的輸出,覆蓋不同場景的多種 XSS 漏洞,從而實現對 XSS 漏洞進行快速、深度、精準地探測。

查看原文 >>
相關文章