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 值。所有這些都是我們感興趣的重要測試內容。
使用已經得到的電子表格並列出各種用來測試 XSS 漏洞的方法。我們稍候將討論各種方法，但是現在先讓我們看看我的電子表格的屏幕截圖，請注意，我列出了頁面上允許的每個值以及每個值的所有測試類型。這種記錄測試的方法僅是我自己的習慣，您可以使用自己的方法。我喜歡記錄所有東西，以便我能知道已經做了哪些工作和哪些工作沒有做。
5. 開始測試並注意輸出結果
在查找漏洞的過程中，最重要的部分並不是您是否找到了漏洞。而是您是否真正知道究竟發生了哪些事情。對於 XSS，只需檢查 HTML 輸出並看看您輸入的內容在什麼地方。它在一個 HREF 標記中嗎？是否在 IFRAME 標記中？它在 CLSID 標記中嗎？在 IMG SRC 中嗎？某些 Flash 內容的 PARAM NAME 是怎樣的？我會檢查所有這些情況，如果您對所輸入內容的目的十分了解，可以調整您的測試來找出問題。這意味着您可能需要添加一個額外的封閉括號“>”來讓某個標記變得完整，或者添加一個雙引號來關閉標記內的一個元素。或者，您可能需要使用 URL 或 HTML 來編碼您的字符，例如將雙引號變爲 %22 或 "。嗯，並不那麼容易，這個站點看來防範比較嚴密。現在該怎麼辦呢？那麼，也許您的簡單測試用例 <script>alert(‘hi’)</script> 並不能產生期望中的警告對話框。仔細想想這個問題並在可能的情況下與開發人員進行交流。也許他們對輸入中的尖括號、單引號或圓括號進行了過濾。也許他們會過濾“script”這個詞。重新研究爲何輸入會產生這樣的輸出，並理解每個值（查詢字符串、cookie、POST 數據）的作用。“pageId=10”這樣的查詢字符串值可能對輸出沒有影響，因此不值得花費時間測試它。有時，最好試着注入單個字符（例如尖括號、雙引號標記或者圓括號），看看應用程序是否過濾這些字符。然後，便可以知道您面對的過濾級別究竟如何。接着，可以調整測試方法，對這些字符進行編碼並重試，或者尋找其他注入辦法。
改變測試用例
我恐怕無法充分對此進行說明：研究輸入的值會輸出什麼樣的 HTML 頁面非常重要。如果它們不能產生輸出，那麼不要在它們上面浪費時間。如果可以，請進行研究，因爲您需要根據輸出對測試進行相應的修改。我使用了各種變化形式來找出能接受和顯示腳本代碼的參數。因爲這涉及太多內容，因此在這裏無法一一進行討論，但是請務必注意以下幾種情況：
1. >"'><script>alert(‘XSS')</script>
2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5. %22%2Balert(%27XSS%27)%2B%22
6. <table background="javascript:alert(([code])"></table>
7. <object type=text/html data="javascript:alert(([code]);"></object>
8. <body οnlοad="javascript:alert(([code])"></body>
有許多變化形式可以嘗試。關鍵在於瞭解程序究竟使用何種方式處理輸入和顯示輸出頁面。如同這些例子所展示的，常見的變化形式經常是在腳本代碼前面加上 “>””，以嘗試封閉網站可能在輸出中生成的標記。還可以對代碼進行 URL 編碼，嘗試繞過服務器端的輸入過濾功能。此外，因爲尖括號“<>”通常會在輸入時被過濾和從輸出中刪除，所以還必須嘗試不需要尖括號的 XSS，例如 ”&{alert('XSS')};”
持久和動態
找出一個成功的 XSS 頗費周折，因爲在開始時 XSS 攻擊可能並不是那麼顯而易見的。隨便舉一個例子，如果向網站添加一條新留言並在“msgTitle”值中注入代碼，在提交數據後，您可能不會立即看到腳本代碼被執行。但是，當您訪問留言板的時侯，將會在 HTML 頁面中使用“msgTitle”值並將其作爲腳本代碼執行。這種情況被稱作持久性 XSS 攻擊，如果包含腳本代碼的值將被保存到客戶端或者後端系統並在稍候的時間被執行，便會發生此種攻擊。而與此相對的是動態 XSS 攻擊，這種攻擊會立即執行並只發生一次。比如，如果某個鏈接或 GET 請求在某個用來控制頁面輸出的查詢字符串中包含了腳本代碼，那麼在點擊鏈接後會立即顯示輸出。
總結
XSS 測試通常只是整個 Web 應用程序安全性審查工作的一小部分，但是在執行測試時必須細緻和徹底。在多年的工作中，我一直強調使用電子表格或其他方式來記錄站點的所有頁面，以及每個頁面接受的輸入值（查詢字符串、cookie、POST 數據、SOAP），這是在測試前必須進行的一個重要步驟。與此同等重要的是，理解輸入以及它在輸出的 HTML 頁面上的呈現方式。如果您知道了應用程序處理輸入的方式，就會非常迅速地完成許多工作。不要浪費時間測試那些不會作爲輸出顯示的輸入。與開發人員和 PM 進行交流，並在開始測試前建立完善的威脅模型。