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

　　到目前為止,對於跨站點腳本攻擊具有很大的威脅這一點大家並無異議.如果您很精通 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 Title

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

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

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

　　攻擊者可以通過擺脫 <h1> 標記來注入代碼：http://www.somesite.com/page.asp？pageid=10&lang=en&title=Section Title</h1><script>alert（『XSS attack』）</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 值.所有這些都是我們感興趣的重要測試內容.