• <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>
    • 軟件測試技術
    • 軟件測試博客
    • 軟件測試視頻
    • 開源軟件測試技術
    • 軟件測試論壇
    • 軟件測試沙龍
    • 軟件測試資料下載
    • 軟件測試雜志
    • 軟件測試人才招聘
      暫時沒有公告

    字號: | 推薦給好友 上一篇 | 下一篇

    web安全測試-跨站點腳本攻擊

    發布: 2008-7-30 10:33 | 作者: 網絡轉載 | 來源: 網絡轉載 | 查看: 180次 | 進入軟件測試論壇討論

    領測軟件測試網


    web安全測試_跨站點腳本攻擊


    作者:Chris Weber,Casaba Security,LLC

    到目前為止,對于跨站點腳本攻擊具有很大的威脅這一點大家并無異議。如果您很精通 XSS 并且只想看看有什么好的測試方法可供借鑒,那么請直接跳到本文的測試部分。如果您對此一無所知,請按順序認真閱讀!如果某個懷有惡意的人(攻擊者)可以強迫某個不知情的用戶(受害者)運行攻擊者選擇的客戶端腳本,那么便會發生跨站點腳本攻擊!翱缯军c腳本”這個詞應該屬于用詞不當的情況,因為它不僅與腳本有關,而且它甚至不一定是跨站點的。所以,它就是一個在發現這種攻擊時起的一個名字,并且一直沿用至今。從現在開始,我們將使用它常見的縮寫名稱“XSS”。

    XSS 攻擊的過程涉及以下三方:

    • 攻擊者
     
    • 受害者
     
    • 存在漏洞的網站(攻擊者可以使用它對受害者采取行動)
     


    在這三方之中,只有受害者會實際運行攻擊者的代碼。網站僅僅是發起攻擊的一個載體,一般不會受到影響?梢杂枚喾N方式發起 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><scrīpt>alert(‘XSS%20attack’)</scrīpt>

    這個請求的 HTML 輸出將為:
    <h1>Section Title</h1><scrīpt>alert(‘XSS attack’)</scrīpt>

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

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

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

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

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

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

    測試 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 請求非常重要。這樣可以繞過所有的客戶端 javascrīpt 輸入驗證代碼。我在這里要提醒所有 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.
     嗯,并不那么容易,這個站點看來防范比較嚴密,F在該怎么辦呢?
    那么,也許您的簡單測試用例 <scrīpt>alert(‘hi’)</scrīpt> 并不能產生期望中的警告對話框。仔細想想這個問題并在可能的情況下與開發人員進行交流。也許他們對輸入中的尖括號、單引號或圓括號進行了過濾。也許他們會過濾“scrīpt”這個詞。重新研究為何輸入會產生這樣的輸出,并理解每個值(查詢字符串、cookie、POST 數據)的作用!皃ageId=10”這樣的查詢字符串值可能對輸出沒有影響,因此不值得花費時間測試它。有時,最好試著注入單個字符(例如尖括號、雙引號標記或者圓括號),看看應用程序是否過濾這些字符。然后,便可以知道您面對的過濾級別究竟如何。接著,可以調整測試方法,對這些字符進行編碼并重試,或者尋找其他注入辦法。
     


    改變測試用例
    我恐怕無法充分對此進行說明:研究輸入的值會輸出什么樣的 HTML 頁面非常重要。如果它們不能產生輸出,那么不要在它們上面浪費時間。如果可以,請進行研究,因為您需要根據輸出對測試進行相應的修改。我使用了各種變化形式來找出能接受和顯示腳本代碼的參數。因為這涉及太多內容,因此在這里無法一一進行討論,但是請務必注意以下幾種情況:

    1.
     >"'><scrīpt>alert(‘XSS')</scrīpt>
     
    2.
     >%22%27><img%20src%3d%22javascrīpt: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(javascrīpt:alert(%27XSS%27))%22%20OS%22
     
    5.
     %22%2Balert(%27XSS%27)%2B%22
     
    6.
     <table background="javascrīpt:alert(([code])"></table>
     
    7.
     <object type=text/html data="javascrīpt:alert(([code]);"></object>
     
    8.
     <body ōnload="javascrīpt:alert(([code])"></body>
     


    有許多變化形式可以嘗試。關鍵在于了解程序究竟使用何種方式處理輸入和顯示輸出頁面。如同這些例子所展示的,常見的變化形式經常是在腳本代碼前面加上 “>””,以嘗試封閉網站可能在輸出中生成的標記。還可以對代碼進行 URL 編碼,嘗試繞過服務器端的輸入過濾功能。此外,因為尖括號“<>”通常會在輸入時被過濾和從輸出中刪除,所以還必須嘗試不需要尖括號的 XSS,例如 ”&{alert('XSS')};”

    持久和動態
    找出一個成功的 XSS 頗費周折,因為在開始時 XSS 攻擊可能并不是那么顯而易見的。隨便舉一個例子,如果向網站添加一條新留言并在“msgTitle”值中注入代碼,在提交數據后,您可能不會立即看到腳本代碼被執行。但是,當您訪問留言板的時侯,將會在 HTML 頁面中使用“msgTitle”值并將其作為腳本代碼執行。這種情況被稱作持久性 XSS 攻擊,如果包含腳本代碼的值將被保存到客戶端或者后端系統并在稍候的時間被執行,便會發生此種攻擊。

    而與此相對的是動態 XSS 攻擊,這種攻擊會立即執行并只發生一次。比如,如果某個鏈接或 GET 請求在某個用來控制頁面輸出的查詢字符串中包含了腳本代碼,那么在點擊鏈接后會立即顯示輸出。

    總結
    XSS 測試通常只是整個 Web 應用程序安全性審查工作的一小部分,但是在執行測試時必須細致和徹底。在多年的工作中,我一直強調使用電子表格或其他方式來記錄站點的所有頁面,以及每個頁面接受的輸入值(查詢字符串、cookie、POST 數據、SOAP),這是在測試前必須進行的一個重要步驟。與此同等重要的是,理解輸入以及它在輸出的 HTML 頁面上的呈現方式。如果您知道了應用程序處理輸入的方式,就會非常迅速地完成許多工作。不要浪費時間測試那些不會作為輸出顯示的輸入。與開發人員和 PM 進行交流,并在開始測試前建立完善的威脅模型。

    請參見其他本月安全性 MVP 文章專欄.

    必須細致和徹底。在多年的工作中,我一直強調使用電子表格或其他方式來記錄站點的所有頁面,以及每個頁面接受的輸入值(查詢字符串、cookie、POST 數據、SOAP),這是在測試前必須進行的一個重要步驟。與此同等重要的是,理解輸入以及它在輸出的 HTML 頁面上的呈現方式。如果您知道了應用程序處理輸入的方式,就會非常迅速地完成許多工作。不要浪費時間測試那些不會作為輸出顯示的輸入。與開發人員和 PM 進行交流,并在開始測試前建立完善的威脅模型。

     

    延伸閱讀

    文章來源于領測軟件測試網 http://www.kjueaiud.com/

    TAG: web Web WEB 站點腳本 攻擊者 XSS 受害者


    關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
    版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
    北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
    技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

    軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

    老湿亚洲永久精品ww47香蕉图片_日韩欧美中文字幕北美法律_国产AV永久无码天堂影院_久久婷婷综合色丁香五月

  • <ruby id="5koa6"></ruby>
    <ruby id="5koa6"><option id="5koa6"><thead id="5koa6"></thead></option></ruby>

    <progress id="5koa6"></progress>

  • <strong id="5koa6"></strong>