web跨站點腳本攻擊方式和測試方法

1、到目前為止， 對于跨站點腳本攻擊具有很大的威脅這一點大家并無異議。 如果您很精通 XSS 并且只想看看有什么好的測試方法可供借鑒， 那么請直接跳到本文的測試部分。 如果您對此 一無所知， 請按順序認(rèn)真閱讀！ 如果某個懷有惡意的人（攻擊者） 可以強迫某個不知情的用 戶（受害者）運行攻擊者選擇的客戶端腳本， 那么便會發(fā)生跨站點腳本攻擊。 “跨站點腳本” 這個詞應(yīng)該屬于用詞不當(dāng)?shù)那闆r，因為它不僅與腳本有關(guān)，而且它甚至不一定是跨站點的。所以， 它就是一個在發(fā)現(xiàn)這種攻擊時起的一個名字，并且一直沿用至今。從現(xiàn)在開始，我們將使用它常見的縮寫名稱“ XSS”。XSS 攻擊的過程涉及以下三方：? 攻擊者? 受害

2、者? 存在漏洞的網(wǎng)站（攻擊者可以使用它對受害者采取行動）在這三方之中， 只有受害者會實際運行攻擊者的代碼。 網(wǎng)站僅僅是發(fā)起攻擊的一個 載體，一般不會受到影響。 可以用多種方式發(fā)起 XSS 攻擊。例如， 攻擊者可通過電子郵件、 IM 或其他途徑向受害者發(fā)送一個經(jīng)過經(jīng)心構(gòu)造的惡意URL 。當(dāng)受害者在 Web 瀏覽器中打開該 URL 的時侯，網(wǎng)站會顯示一個頁面并在受害者的計算機上執(zhí)行腳本。XSS 漏洞是什么樣的呢？作為一名 Web 開發(fā)人員或測試人員，您肯定知道 Web 應(yīng)用程序的技術(shù)基礎(chǔ)是由 HTTP 和 HTML 組成的。 HTTP 協(xié)議是 HTML 的傳輸機制，可使用代碼設(shè)計 Web 頁面 布

3、局和生成頁面。如果 Web 應(yīng)用程序接受用戶通過 HTTP 請求（如 GET 或 POST）提交的輸入 信息，然后使用輸出 HTML 代碼在某些地方顯示這些信息，便可能存在 XSS 漏洞。下面 是一個最簡單的例子：Web 請求如下所示：GET在發(fā)出請求后，服務(wù)器返回的 HTML 內(nèi)容包括： Section Title可以看到，傳遞給“ title ”查詢字符串參數(shù)的用戶輸入可能被保存在一個字符串 變量中并且由 Web 應(yīng)用程序插入到 標(biāo)記中。通過提供輸入內(nèi)容，攻擊者可以控制 HTML ?，F(xiàn)在，如果站點沒有在服務(wù)器端對用戶輸入加以過濾（因為總是可以繞過客戶端控件），那么惡意用戶便可以使用許多手段

4、對此漏洞加以濫用：攻擊者可以通過擺脫 標(biāo)記來注入代碼： alert( XSS%20attack )這個請求的 HTML 輸出將為：XSS attack )Section Titlealert(即便是這個最簡單的例子， 攻擊者也可以利用此連接完成數(shù)不清的事情。 讓我們看看會 有哪些潛在的威脅，然后討論一些更高級的測試方法。XSS 攻擊的威脅有多么嚴(yán)重？由于能夠在生成的 Web 頁面中注入代碼， 能想到的威脅有多么嚴(yán)重， 就可以有多 么嚴(yán)重的威脅。攻擊者可以使用 XSS 漏洞竊取 Cookie ，劫持帳戶，執(zhí)行 ActiveX ，執(zhí)行 Flash 內(nèi)容，強迫您下載軟件，或者是對硬盤和數(shù)據(jù)采取操作。

5、只要您點擊了某些 URL ，這一切便有可能發(fā)生。每天之中，在閱讀來自留言板或新聞組的 受信任的電子郵件的時侯，您會多少次地單擊其中的URL ？網(wǎng)絡(luò)釣魚攻擊通常利用 XSS 漏洞來裝扮成合法站點?？梢钥吹胶芏噙@樣的情況， 比如您的銀行給你發(fā)來了一封電子郵件， 向您告知對您的帳戶進行了一些修改并誘使您點擊 某些超鏈接。如果仔細(xì)觀察這些URL ，它們實際上可能利用了銀行網(wǎng)站中存在的漏洞，它們的形式類似于 alert( XSS) ，這里利用了“ redirect”參數(shù)來執(zhí)行攻擊。如果您足夠狡猾的話， 可以將管理員定為攻擊目標(biāo)， 您可以發(fā)送一封具有如下主題 的郵件：“求救！這個網(wǎng)站地址總是出現(xiàn)錯誤！ ”

6、在管理員打開該 URL 后，便可以執(zhí)行許多 惡意操作，例如竊取他(或她)的憑證。好了，現(xiàn)在我們已經(jīng)理解了它的危害性 - 危害用戶，危害管理員，給公司帶來壞 的公共形象?，F(xiàn)在，讓我們看看本文的重點 - 測試您的網(wǎng)站是否存在這些問題。測試 XSS 漏洞多年以來， 我一直是一名全職的安全顧問， 已經(jīng)做過無數(shù)次的這種測試了。 我將好 的測試計劃歸結(jié)為兩個字： 徹底。 對于你我來說， 查找這些漏洞與能夠有機會在 Bugtraq 或 Vulnwatch 上吹噓一番沒有任何關(guān)系； 它只與如何出色完成負(fù)責(zé)的工作有關(guān)。 如果這意味著 對應(yīng)用程序中所有的單個查詢字符串參數(shù)、 cookie 值 以及 POST 數(shù)據(jù)

7、值進行檢查，那么 這只能表明我們的工作還不算太艱巨。XSS 漏洞那樣簡SQL 注入、身份比如，在測試 XSS顯然，一次完整的安全性檢查所涉及的內(nèi)容通常遠(yuǎn)遠(yuǎn)超出尋找單；它需要建立整體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、 驗證和授權(quán)錯誤。 好在執(zhí)行這樣徹底的工作時， 各個領(lǐng)域之間都存在重疊。漏洞時，經(jīng)常會同時找出錯誤處理或信息泄漏問題。我假設(shè)您屬于某個負(fù)責(zé)對 Web 應(yīng)用程序進行開發(fā)和測試的小組。 在這個幸運的位置上， 您可以混合使用黑盒和白盒方法。 每種方法都有它自己的優(yōu)點， 結(jié)合使用時甚至能相 互提供支持。按順序準(zhǔn)備您的工具包測試工作也可以是自動化的， 但是我們在這里只討論手動操作。

8、 手動測試的必備工 具包括：? Paros proxy () ，用于截獲 HTTP 通信數(shù)據(jù)? Fiddler () ，用于截獲 HTTP 通信數(shù)據(jù)? Burp proxy ()? TamperIE () ，用于修改 GET 和 POST我們以上至少列出了三種 Web 代理軟件。 也可以尋找其他不同的類似產(chǎn)品， 因為 每種產(chǎn)品都有它自己的獨到之處。下面，您需要在 Web 瀏覽器發(fā)出 HTTP 請求之前截獲 這些請求，并修改它們以注入 XSS 測試代碼。上面所有這些工具都可以完成這項任務(wù)，某 些工具還會顯示返回的 HTML 源代碼(如果您選擇了截獲服務(wù)器響應(yīng)) 。 截獲客戶端發(fā)出的 GET 和

9、POST 請求非常重要。這樣可以繞過所有的客戶端 javascript 輸入驗證代碼。我在這里要提醒所有 Web 開發(fā)人員 - 客戶端安全控制是靠不住的。應(yīng)該 總是在服務(wù)器端執(zhí)行有效性驗證。確定站點及其功能 - 與開發(fā)人員和 PM 交流 繪制一些簡單的數(shù)據(jù)流圖表， 對站點上的頁面及其功能進行描述。 此時， 可以安排 一些與開發(fā)人員和項目經(jīng)理的會議來建立威脅模型。 在會議上盡可能對應(yīng)用程序進行深入探 討。站點公開了 Web 服務(wù)嗎？是否有身份驗證表單？有留言板嗎？有用戶設(shè)置頁面嗎？確 保列出了所有這些頁面。找出并列出所有由用戶提供輸入的點 對站點地圖進行進一步細(xì)化。 我通常會為此創(chuàng)建一個電子表格

10、。 對于每個頁面， 列 出所有查詢字符串參數(shù)、 cookie 值、自定義 HTTP 標(biāo)頭、 POST 數(shù)據(jù)值和以其他形式傳遞 的用戶輸入。不要忘記搜索 Web 服務(wù)和類似的 SOAP 請求，并找出所有允許用戶輸入的 字段。分別列出每個輸入?yún)?shù)， 因為下面需要獨立測試每個參數(shù)。 這可能是最重要的一個 步驟！如果閱讀下面的電子表格，您會看到我已經(jīng)在示例站點中找出了一大堆這樣的東西。 如 forwardURL 和 lang 這樣的查詢字符串。如 name、 password、 msgBody 、 msgTitle 和 這樣的 POST 數(shù)據(jù)，甚至某些 Cookie 值。所有這些都是我們感興趣的重要測

11、試內(nèi)容。認(rèn)真思考并列出測試用例使用已經(jīng)得到的電子表格并列出各種用來測試XSS 漏洞的方法。 我們稍候?qū)⒂懻摳鞣N方法， 但是現(xiàn)在先讓我們看看我的電子表格的屏幕截圖， 請注意， 我列出了頁面上允許 的每個值以及每個值的所有測試類型。 這種記錄測試的方法僅是我自己的習(xí)慣， 您可以使用 自己的方法。我喜歡記錄所有東西，以便我能知道已經(jīng)做了哪些工作和哪些工作沒有做。開始測試并注意輸出結(jié)果在查找漏洞的過程中， 最重要的部分并不是您是否找到了漏洞。 而是您是否真正知 道究竟發(fā)生了哪些事情。對于XSS，只需檢查 HTML 輸出并看看您輸入的內(nèi)容在什么地方。它在一個 HREF 標(biāo)記中嗎？是否在 IFRAME 標(biāo)

12、記中？它在 CLSID 標(biāo)記中嗎？在 IMG SRC 中嗎？某些 Flash 內(nèi)容的 PARAM NAME 是怎樣的？我會檢查所有這些情況， 如果您對所輸入內(nèi)容的目的十分了解， 可以調(diào)整您的測試 來找出問題。這意味著您可能需要添加一個額外的封閉括號“”來讓某個標(biāo)記變得完整，或者添加一個雙引號來關(guān)閉標(biāo)記內(nèi)的一個元素。或者，您可能需要使用 URL 或 HTML 來 編碼您的字符，例如將雙引號變?yōu)?%22 或 。嗯，并不那么容易，這個站點看來防范比較嚴(yán)密。現(xiàn)在該怎么辦呢？那么，也許您的簡單測試用例alert( hi ) 并不能產(chǎn)生期望中的警告對話框。 仔細(xì)想想這個問題并在可能的情況下與開發(fā)人員進行交

13、流。 也許他們對輸入中 的尖括號、單引號或圓括號進行了過濾。也許他們會過濾“script ”這個詞。重新研究為何輸入會產(chǎn)生這樣的輸出，并理解每個值(查詢字符串、cookie 、 POST 數(shù)據(jù))的作用?！?pageId=10”這樣的查詢字符串值可能對輸出沒有影響，因此不值得花費時間測試它。有 時，最好試著注入單個字符(例如尖括號、雙引號標(biāo)記或者圓括號) ，看看應(yīng)用程序是否過 濾這些字符。然后，便可以知道您面對的過濾級別究竟如何。接著，可以調(diào)整測試方法，對 這些字符進行編碼并重試，或者尋找其他注入辦法。我恐怕無法充分對此進行說明： 研究輸入的值會輸出什么樣的 HTML 頁面非常重要。 如果 它們

14、不能產(chǎn)生輸出， 那么不要在它們上面浪費時間。如果可以，請進行研究， 因為您需要根 據(jù)輸出對測試進行相應(yīng)的修改。我使用了各種變化形式來找出能接受和顯示腳本代碼的參 數(shù)。因為這涉及太多內(nèi)容，因此在這里無法一一進行討論，但是請務(wù)必注意以下幾種情況：alert( XSS)%22%27AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27)%22%20OS%22%22%2Balert(%27XSS%27)%2B%22有許多變化形式可以嘗試。 關(guān)鍵在于了解程序究竟使用何種方式處理輸入和顯示輸 出頁面。如同這些例子所展示的，常見的變化形式經(jīng)常

15、是在腳本代碼前面加上“ ”，以嘗試封閉網(wǎng)站可能在輸出中生成的標(biāo)記。 還可以對代碼進行 URL 編碼， 嘗試?yán)@過服務(wù)器端 的輸入過濾功能。此外，因為尖括號“ ”通常會在輸入時被過濾和從輸出中刪除，所以還必須嘗試不需要尖括號的 XSS，例如 ” &alert(XSS); ”持久和動態(tài)找出一個成功的 XSS 頗費周折， 因為在開始時 XSS 攻擊可能并不是那么顯而易 見的。隨便舉一個例子，如果向網(wǎng)站添加一條新留言并在“msgTitle ”值中注入代碼，在提交數(shù)據(jù)后，您可能不會立即看到腳本代碼被執(zhí)行。但是，當(dāng)您訪問留言板的時侯，將會在 HTML 頁面中使用“ msgTitle ”值并將其作為腳本代碼執(zhí)行。 這種情況被稱作持久性 XSS 攻 擊，如果包含腳本代碼的值將被保存到客戶端或者后端系統(tǒng)并在稍候的時間被執(zhí)行， 便會發(fā) 生此種攻擊。而與此相對的是動態(tài) XSS 攻擊，這種攻擊會立即執(zhí)行并只發(fā)生一次。比如，如果 某個鏈接或 GET 請求在某個用來控制頁面輸出的查詢字符串中包含了腳本代碼， 那么在點 擊鏈接后會立即顯示輸出?？偨Y(jié)XSS 測試通常只是整個 Web 應(yīng)用程序安全性審查工作的