5.開始測試并注意輸出結果
在查找漏洞的過程中，最重要的部分并不是您是否找到了漏洞。而是您是否真正知道究竟發生了哪些事情。對于 XSS，只需檢查 HTML 輸出并看看您輸入的內容在什么地方。它在一個 HREF 標記中嗎?是否在 IFRAME 標記中?它在 CLSID 標記中嗎?在 IMG SRC 中嗎?某些 Flash 內容的 PARAM NAME 是怎樣的?
我會檢查所有這些情況，如果您對所輸入內容的目的十分了解，可以調整您的測試來找出問題。這意味著您可能需要添加一個額外的封閉括號“>”來讓某個標記變得完整，或者添加一個雙引號來關閉標記內的一個元素�；蛘�，您可能需要使用 URL 或 HTML 來編碼您的字符，例如將雙引號變為 %22 或 。
6.嗯，并不那么容易，這個站點看來防范比較嚴密�，F在該怎么辦呢?
那么，也許您的簡單測試用例 alert(‘hi’) 并不能產生期望中的警告對話框。仔細想想這個問題并在可能的情況下與開發人員進行交流。也許他們對輸入中的尖括號、單引號或圓括號進行了過濾。也許他們會過濾“scrīpt”這個詞。重新研究為何輸入會產生這樣的輸出，并理解每個值(查詢字符串、cookie、POST 數據)的作用�！皃ageId=10”這樣的查詢字符串值可能對輸出沒有影響，因此不值得花費時間測試它。有時，最好試著注入單個字符(例如尖括號、雙引號標記或者圓括號)，看看應用程序是否過濾這些字符。然后，便可以知道您面對的過濾級別究竟如何。接著，可以調整測試方法，對這些字符進行編碼并重試，或者尋找其他注入辦法。
改變測試用例
我恐怕無法充分對此進行說明：研究輸入的值會輸出什么樣的 HTML 頁面非常重要。如果它們不能產生輸出，那么不要在它們上面浪費時間。如果可以，請進行研究，因為您需要根據輸出對測試進行相應的修改。我使用了各種變化形式來找出能接受和顯示腳本代碼的參數。因為這涉及太多內容，因此在這里無法一一進行討論，但是請務必注意以下幾種情況： 軟件測試
1.>"'>
2.>%22%27>javascrīpt />
3.>"'>
4.AK%22%20style%3D%22background:url(javascrīpt:alert(%27XSS%27))%22%20OS%22
5.%22%2Balert(%27XSS%27)%2B%22
6.
7.
8.
有許多變化形式可以嘗試。關鍵在于了解程序究竟使用何種方式處理輸入和顯示輸出頁面。如同這些例子所展示的，常見的變化形式經常是在腳本代碼前面加上 “>””，以嘗試封閉網站可能在輸出中生成的標記。還可以對代碼進行 URL 編碼，嘗試繞過服務器端的輸入過濾功能。此外，因為尖括號“<>”通常會在輸入時被過濾和從輸出中刪除，所以還必須嘗試不需要尖括號的 XSS，例如 ”&{alert(XSS)};”
持久和動態
找出一個成功的 XSS 頗費周折，因為在開始時 XSS 攻擊可能并不是那么顯而易見的。隨便舉一個例子，如果向網站添加一條新留言并在“msgTitle”值中注入代碼，在提交數據后，您可能不會立即看到腳本代碼被執行。但是，當您訪問留言板的時侯，將會在 HTML 頁面中使用“msgTitle”值并將其作為腳本代碼執行。這種情況被稱作持久性 XSS 攻擊，如果包含腳本代碼的值將被保存到客戶端或者后端系統并在稍候的時間被執行，便會發生此種攻擊。
而與此相對的是動態 XSS 攻擊，這種攻擊會立即執行并只發生一次。比如，如果某個鏈接或 GET 請求在某個用來控制頁面輸出的查詢字符串中包含了腳本代碼，那么在點擊鏈接后會立即顯示輸出。
總結
XSS 測試通常只是整個 Web 應用程序安全性審查工作的一小部分，但是在執行測試時必須細致和徹底。在多年的工作中，我一直強調使用電子表格或其他方式來記錄站點的所有頁面，以及每個頁面接受的輸入值(查詢字符串、cookie、POST 數據、SOAP)，這是在測試前必須進行的一個重要步驟。與此同等重要的是，理解輸入以及它在輸出的 HTML 頁面上的呈現方式。如果您知道了應用程序處理輸
入的方式，就會非常迅速地完成許多工作。不要浪費時間測試那些不會作為輸出顯示的輸入。與開發人員和 PM 進行交流，并在開始測試前建立完善的威脅模型。
必須細致和徹底。在多年的工作中，我一直強調使用電子表格或其他方式來記錄站點的所有頁面，以及每個頁面接受的輸入值(查詢字符串、cookie、POST 數據、SOAP)，這是在測試前必須進行的一個重要步驟。與此同等重要的是，理解輸入以及它在輸出的 HTML 頁面上的呈現方式。如果您知道了應用程序處理輸入的方式，就會非常迅速地完成許多工作。不要浪費時間測試那些不會作為輸出顯示的輸入。與開發人員和 PM 進行交流，并在開始測試前建立完善的威脅模型。
文章來源于領測軟件測試網 http://www.kjueaiud.com/