測試Web應用程序是否存在跨站點腳本漏洞(XSS)

測試Web應用程序是否存在跨站點腳本漏洞2008年05月26日 星期一 01:37到目前爲止，對於跨站點腳本攻擊具有很大的威脅這一點大家並無異議。如果您很精通 XSS 並且只想看看有什麼好的測試方法可供借鑑，那麼請直接跳到本文的測試部分。如果您對此一無所知，請按順序認真閱讀！如果某個懷有惡意的人（攻擊者）可以強迫某個不知情的用戶（受害者）運行攻擊者選擇的客戶端腳本，那麼便會發生跨站點腳本攻擊。“跨站點腳本”這個詞應該屬於用詞不當的情況，因爲它不僅與腳本有關，而且它甚至不一定是跨站點的。所以，它就是一個在發現這種攻擊時起的一個名字，並且一直沿用至今。從現在開始，我們將使用它常見的縮寫名稱 “XSS”。
XSS 攻擊的過程涉及以下三方：
• 攻擊者
• 受害者
• 存在漏洞的網站（攻擊者可以使用它對受害者採取行動）

在這三方之中，只有受害者會實際運行攻擊者的代碼。網站僅僅是發起攻擊的一個載體，一般不會受到影響。可以用多種方式發起 XSS 攻擊。例如，攻擊者可通過電子郵件、IM 或其他途徑向受害者發送一個經過經心構造的惡意 URL。當受害者在 Web 瀏覽器中打開該 URL 的時侯，網站會顯示一個頁面並在受害者的計算機上執行腳本。

XSS 漏洞是什麼樣的呢？
作爲一名 Web 開發人員或測試人員，您肯定知道 Web 應用程序的技術基礎是由 HTTP 和 HTML 組成的。HTTP 協議是 HTML 的傳輸機制，可使用代碼設計 Web 頁面佈局和生成頁面。

如果 Web 應用程序接受用戶通過 HTTP 請求（如 GET 或 POST）提交的輸入信息，然後使用輸出 HTML 代碼在某些地方顯示這些信息，便可能存在 XSS 漏洞。下面是一個最簡單的例子：

1. Web 請求如下所示：
GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. 在發出請求後，服務器返回的 HTML 內容包括：
<h1>Section Title</h1>

可以看到，傳遞給“title”查詢字符串參數的用戶輸入可能被保存在一個字符串變量中並且由 Web 應用程序插入到 <h1> 標記中。通過提供輸入內容，攻擊者可以控制 HTML。

3. 現在，如果站點沒有在服務器端對用戶輸入加以過濾（因爲總是可以繞過客戶端控件），那麼惡意用戶便可以使用許多手段對此漏洞加以濫用：

攻擊者可以通過擺脫 <h1> 標記來注入代碼：
http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><script>alert(‘XSS%20attack’)</script>

這個請求的 HTML 輸出將爲：
<h1>Section Title</h1><script>alert(‘XSS attack’)</script>

即便是這個最簡單的例子，攻擊者也可以利用此連接完成數不清的事情。讓我們看看會有哪些潛在的威脅，然後討論一些更高級的測試方法。

XSS 攻擊的威脅有多麼嚴重？
由於能夠在生成的 Web 頁面中注入代碼，能想到的威脅有多麼嚴重，就可以有多麼嚴重的威脅。攻擊者可以使用 XSS 漏洞竊取 Cookie，劫持帳戶，執行 ActiveX，執行 Flash 內容，強迫您下載軟件，或者是對硬盤和數據採取操作。

只要您點擊了某些 URL，這一切便有可能發生。每天之中，在閱讀來自留言板或新聞組的受信任的電子郵件的時侯，您會多少次地單擊其中的 URL？

網絡釣魚攻擊通常利用 XSS 漏洞來裝扮成合法站點。可以看到很多這樣的情況，比如您的銀行給你發來了一封電子郵件，向您告知對您的帳戶進行了一些修改並誘使您點擊某些超鏈接。如果仔細觀察這些 URL，它們實際上可能利用了銀行網站中存在的漏洞，它們的形式類似於 http://mybank.com/somepage?redirect=<script>alert(‘XSS’)</script>，這裏利用了“redirect”參數來執行攻擊。

如果您足夠狡猾的話，可以將管理員定爲攻擊目標，您可以發送一封具有如下主題的郵件：“求救！這個網站地址總是出現錯誤！”在管理員打開該 URL 後，便可以執行許多惡意操作，例如竊取他（或她）的憑證。

好了，現在我們已經理解了它的危害性 -- 危害用戶，危害管理員，給公司帶來壞的公共形象。現在，讓我們看看本文的重點 -- 測試您的網站是否存在這些問題。

測試 XSS 漏洞
多年以來，我一直是一名全職的安全顧問，已經做過無數次的這種測試了。我將好的測試計劃歸結爲兩個字：徹底。對於你我來說，查找這些漏洞與能夠有機會在 Bugtraq 或 Vulnwatch 上吹噓一番沒有任何關係；它只與如何出色完成負責的工作有關。如果這意味着對應用程序中所有的單個查詢字符串參數、cookie 值 以及 POST 數據值進行檢查，那麼這隻能表明我們的工作還不算太艱鉅。

顯然，一次完整的安全性檢查所涉及的內容通常遠遠超出尋找 XSS 漏洞那樣簡單；它需要建立整體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和授權錯誤。好在執行這樣徹底的工作時，各個領域之間都存在重疊。比如，在測試 XSS 漏洞時，經常會同時找出錯誤處理或信息泄漏問題。

我假設您屬於某個負責對 Web 應用程序進行開發和測試的小組。在這個幸運的位置上，您可以混合使用黑盒和白盒方法。每種方法都有它自己的優點，結合使用時甚至能相互提供支持。

1.按順序準備您的工具包
測試工作也可以是自動化的，但是我們在這裏只討論手動操作。手動測試的必備工具包括：
• Paros proxy ( http://www.parosproxy.org )，用於截獲 HTTP 通信數據
• Fiddler ( http://www.fiddlertool.com/fiddler )，用於截獲 HTTP 通信數據
• Burp proxy ( http://www.portswigger.net/proxy/ )
• TamperIE ( http://www.bayden.com/dl/TamperIESetup.exe )，用於修改 GET 和 POST

我們以上至少列出了三種 Web 代理軟件。也可以尋找其他不同的類似產品，因爲每種產品都有它自己的獨到之處。下面，您需要在 Web 瀏覽器發出 HTTP 請求之前截獲這些請求，並修改它們以注入 XSS 測試代碼。上面所有這些工具都可以完成這項任務，某些工具還會顯示返回的 HTML 源代碼（如果您選擇了截獲服務器響應）。

截獲客戶端發出的 GET 和 POST 請求非常重要。這樣可以繞過所有的客戶端 javascript 輸入驗證代碼。我在這裏要提醒所有 Web 開發人員 -- 客戶端安全控制是靠不住的。應該總是在服務器端執行有效性驗證。

2.確定站點及其功能 -- 與開發人員和 PM 交流
繪製一些簡單的數據流圖表，對站點上的頁面及其功能進行描述。此時，可以安排一些與開發人員和項目經理的會議來建立威脅模型。在會議上儘可能對應用程序進行深入探討。站點公開了 Web 服務嗎？是否有身份驗證表單？有留言板嗎？有用戶設置頁面嗎？確保列出了所有這些頁面。

3.找出並列出所有由用戶提供輸入的點
對站點地圖進行進一步細化。我通常會爲此創建一個電子表格。對於每個頁面，列出所有查詢字符串參數、cookie 值、自定義 HTTP 標頭、POST 數據值和以其他形式傳遞的用戶輸入。不要忘記搜索 Web 服務和類似的 SOAP 請求，並找出所有允許用戶輸入的字段。

分別列出每個輸入參數，因爲下面需要獨立測試每個參數。這可能是最重要的一個步驟！如果閱讀下面的電子表格，您會看到我已經在示例站點中找出了一大堆這樣的東西。如 forwardURL 和 lang 這樣的查詢字符串。如 name、password、msgBody、msgTitle 和這樣的 POST 數據，甚至某些 Cookie 值。所有這些都是我們感興趣的重要測試內容。

4.認真思考並列出測試用例
使用已經得到的電子表格並列出各種用來測試 XSS 漏洞的方法。我們稍候將討論各種方法，但是現在先讓我們看看我的電子表格的屏幕截圖，請注意，我列出了頁面上允許的每個值以及每個值的所有測試類型。這種記錄測試的方法僅是我自己的習慣，您可以使用自己的方法。我喜歡記錄所有東西，以便我能知道已經做了哪些工作和哪些工作沒有做。

5.開始測試並注意輸出結果
在查找漏洞的過程中，最重要的部分並不是您是否找到了漏洞。而是您是否真正知道究竟發生了哪些事情。對於 XSS，只需檢查 HTML 輸出並看看您輸入的內容在什麼地方。它在一個 HREF 標記中嗎？是否在 IFRAME 標記中？它在 CLSID 標記中嗎？在 IMG SRC 中嗎？某些 Flash 內容的 PARAM NAME 是怎樣的？

我會檢查所有這些情況，如果您對所輸入內容的目的十分了解，可以調整您的測試來找出問題。這意味着您可能需要添加一個額外的封閉括號“>”來讓某個標記變得完整，或者添加一個雙引號來關閉標記內的一個元素。或者，您可能需要使用 URL 或 HTML 來編碼您的字符，例如將雙引號變爲 %22 或 "。

6.嗯，並不那麼容易，這個站點看來防範比較嚴密。現在該怎麼辦呢？
那麼，也許您的簡單測試用例 <script>alert(‘hi’)</script> 並不能產生期望中的警告對話框。仔細想想這個問題並在可能的情況下與開發人員進行交流。也許他們對輸入中的尖括號、單引號或圓括號進行了過濾。也許他們會過濾“script”這個詞。重新研究爲何輸入會產生這樣的輸出，並理解每個值（查詢字符串、cookie、POST 數據）的作用。“pageId=10”這樣的查詢字符串值可能對輸出沒有影響，因此不值得花費時間。