Web十大安全隱患之XSS跨站腳本

   上次提到的是sql注入，算是較大的安全隱患，今天我們來介紹另外一種較爲嚴重的安全隱患--XSS跨站腳本***。
       
       首先咱們來說什麼是跨站腳本***。它的英文叫“CrossSite Scripting”，通俗點說就是***者向web頁面裏跨站的插入惡意html代碼，那麼當用戶瀏覽該頁的時候，嵌入到web中的html代碼就會被執行。我們經常看到的重定向啊，以及一些釣魚網站，大多數利用的就是這種技術。比如有個廣告，裏邊網址是item.taobao.com/.xxxx的，是某個人在某論壇發的廣告鏈接，你覺得東西很便宜啊，又是淘寶的，有保障，就點擊進去了。其實呢，它會redirect到另一個***者自己的網站，你在上面通過他的接口付款時候，就會不小心被他洗劫一空。

       介紹過了，其實老實講，我自己對怎麼***和***的原理也不是特別特別瞭解（大多數時候我們只要知道怎麼測試出來有這個隱患和怎麼防止就ok了）。不過大致原理咱們還是要了解的，後面是我節選自百度空間一篇文章，具體作者和鏈接我都忘記了。。是很久之前存下的，在這先感謝下。大家可以簡單瞭解下其原理。

傳統的跨站利用方式一般都是***者先構造一個跨站網頁，然後在另一空間裏放一個收集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***分成三類，Stored XSS、Reflected XSS、Dom-Base XSS。我們逐一介紹下。

       首先是Stored XSS，就是存儲式跨站***。這是最爲厲害的一種***方式，也是測試起來相對容易的。存儲式跨站***簡單來說就是***者提交給網站的數據呢會提交併永久保存到服務器的數據庫或者是文件系統等其他地方，之後不做任何編碼操作就會顯示在web頁面上。貌似說的不是很清楚，我們可以舉個例子來說：

       比如說一個社交網站或其他可以給在網站中留言的地方，事實上呢，我們在可以留言的地方寫入一段代碼：

1. <script>alert(document.cookie)</script>

複製代碼

這樣這個信息就被存儲到了服務器上，當有其他用戶訪問這個網頁時候，其瀏覽器就會執行這個腳本，從而彈出一個關於cookie的alert。類似下圖所示。

                                     

         我們就完成一次最簡單的存儲式跨站***。到目前爲止最典型的存儲式跨站***的例子就是05年myspace發現的漏洞，具體情況大家自行google~~~



       其次Reflected XSS，反射跨站腳本***。這個是最著名最常見的***手段。所謂反射，就是等着服務器所給的返回。我們在進行測試行依據的就是在自己頁面上的簡單注入。在web客戶端提交了數據後，服務端馬上給這個請求生成返回結果頁，如果結果中包含了未驗證的客戶端輸入數據，那就表示會允許客戶端腳本直接注入到頁面裏，也就出現了這樣一個漏洞。簡單舉個例子，在搜索引擎裏邊，我們如果搜索了一個包含html代碼的字符串，如果返回的字符串仍然沒被編碼，那就是存在XSS漏洞了。呃，我自己說的也比較暈，不知道大家能理解沒有。

       這個漏洞乍聽上去比較不嚴重，反正覺得只能在自己頁面上注入代碼嘛，但是其實只要有一些工程學方法，***者就可以誘使其他用戶訪問一個在結果中注入了代碼的url，使***者擁有整個頁面的權限。（具體的工程學方法。。我也不會，要是我會估計我就不在這裏敲字了哈）



       剛纔說了三類，最後一類就是基於DOM的XSS***。由於我是做web測試的，這類相對見的比較少，該漏洞多見於客戶端腳本，意思就是如果一個js訪問需要參數的url，並且需要把信息用於自己頁面，信息又未被編碼，就會出現該漏洞。是不是太抽象了？好吧，我簡化一下，我們是不是經常看到一個網站（比如我們論壇）在網址後邊帶個參數（？XXX的），當看到這種情況時候，我們可以在參數後邊加點料，加個<script></script>的，如果加了這個參數之後的結果不被編碼就輸出，那就證明它具有這麼一個漏洞。

      舉個例子吧，比如某某網站，我們輸入一個這樣的url去請求：

1. http://server.com/XXX.php?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

複製代碼

如果這個腳本被執行了，那麼我們就說他有這樣一個漏洞

（該系列搬運自本人論壇帖~）