上次提到的是sql注入，算是較大的安全隱患，今天我們來介紹另外一種較為嚴重的安全隱患--XSS跨站腳本攻擊。
首先咱們來說什么是跨站腳本攻擊。它的英文叫“CrossSite Scripting”，通俗點說就是攻擊者向
web頁面里跨站的插入惡意html代碼，那么當(dāng)用戶瀏覽該頁的時候，嵌入到web中的html代碼就會被執(zhí)行。我們經(jīng)常看到的重定向啊，以及一些釣魚網(wǎng)站，大多數(shù)利用的就是這種技術(shù)。比如有個廣告，里邊網(wǎng)址是item.taobao.com/.xxxx的，是某個人在某論壇發(fā)的廣告鏈接，你覺得東西很便宜啊，又是淘寶的，有保障，就點擊進去了。其實呢，它會redirect到另一個攻擊者自己的網(wǎng)站，你在上面通過他的接口付款時候，就會不小心被他洗劫一空。
介紹過了，其實老實講，我自己對怎么攻擊和攻擊的原理也不是特別特別了解（大多數(shù)時候我們只要知道怎么
測試出來有這個隱患和怎么防止就ok了）。不過大致原理咱們還是要了解的，后面是我節(jié)選自
百度空間一篇
文章，具體作者和鏈接我都忘記了。。是很久之前存下的，在這先感謝下。大家可以簡單了解下其原理。
傳統(tǒng)的跨站利用方式一般都是攻擊者先構(gòu)造一個跨站網(wǎng)頁，然后在另一空間里放一個收集cookie的頁面，接著結(jié)合其它技術(shù)讓用戶打開跨站頁面以盜取用戶的cookie，以便進一步的攻擊。這種方式太過于落后，對于弊端大家可能都知道，因為即便你收集到了cookie你也未必能進一步滲透進去，多數(shù)的cookie里面的密碼都是經(jīng)過加密的，如果想要cookie欺騙的話，同樣也要受到其它的條件的限約。而另一種思路，則從一定程度上解決上述的問題。比較成熟的方法是通過跨站構(gòu)造一個表單，表單的內(nèi)容則為利用程序的備份功能或者加管理員等功能得到一個高權(quán)限。下面將詳細的介紹這種技術(shù)。
尋找跨站漏洞
如果有代碼的話比較好辦，我們主要看代碼里對用戶輸入的地方和變量有沒有做長度和對”<”,”>”,”;”,”’”等字符是否做過濾。還有要注意的是對于標簽的閉合，像測試QQ群跨站漏洞的時候，你在標題處輸入<script>alert(‘
test’)</script>，代碼是不會被執(zhí)行的，因為在源代碼里，有其它的標簽未閉合，如少了一個</script>，這個時候，你只要閉合一個</script>，代碼就會執(zhí)行，如：你在標題處輸入</script><script>alert(‘test’)</script>，這樣就可以彈出一個test的框。
如何利用
跨站腳本(Cross-site scripting，XSS)漏洞是Web應(yīng)用程序中最常見的漏洞之一。如果您的站點沒有預(yù)防XSS漏洞的固定方法，那么就存在XSS漏洞。這個利用XSS漏洞的病毒之所以具有重要意義是因為，通常難以看到XSS漏洞的威脅，而該病毒則將其發(fā)揮得淋漓盡致。
這個利用XSS漏洞的蠕蟲病毒的特別之處在于它能夠自我傳播。myspace.com上的一個用戶希望自己能夠在網(wǎng)站的友人列表上更“受歡迎”。但是該用戶不是通過普通的方法來結(jié)交新朋友，而是在自己的個人信息中添加了一些代碼，導(dǎo)致其他人在訪問他的頁面時，會不知不覺地利用XSS漏洞將他加為好友。更惡劣的是，它會修改這些人的個人信息，使其他人在訪問這些被感染的個人信息時，也會被感染。由于這種呈指數(shù)傳播的方式，這種病毒才很快就被發(fā)現(xiàn)。
很難預(yù)防站點中的XSS。因此一定要認真檢查您的應(yīng)用程序是否存在XSS漏洞。此外，WebLogic Server的encodeXSS()也可以有所幫助。可以試著針對所有牽涉到使用encodeXSS()或其他某個篩選方法的輸出找出一種編碼模式——找出對一種編碼模式來說不正確的應(yīng)用程序往往要比找出XSS漏洞要容易的多。更重要的是，不要認為，就因為XSS漏洞是一個常見問題，所以它危害不大。
之所以出現(xiàn)XSS漏洞有兩個原因。首先，HTML沒有明確區(qū)分代碼和數(shù)據(jù)。無法確定指出“這個字符串表示的是數(shù)據(jù)”。您可以將其放入引號中，但是數(shù)據(jù)是否包含引號呢？……其次，程序在將用戶數(shù)據(jù)發(fā)送回瀏覽器時沒有進行有效的轉(zhuǎn)義。這導(dǎo)致包含有（例如說）引號的數(shù)據(jù)被放入頁面中，從而引發(fā)了問題。而AJAX要提供的好處是，它包含一個專用渠道XML鏈接，其中全是數(shù)據(jù)而沒有代碼。這樣，就有可能讓客戶端AJAX引擎負責(zé)對字符串進行轉(zhuǎn)義、檢測不正確的值，等等。說是這么說，直到AJAX更為成熟（可能也更為標準化）之前，它只會導(dǎo)致錯誤的編程和安全漏洞。
XSS漏洞可能造成的后果包括竊取用戶會話，竊取敏感信息，重寫Web頁面，重定向用戶到釣魚網(wǎng)站等，尤為嚴重的是，XSS漏洞可能使得攻擊者能夠安裝XSS代理，從而攻擊者能夠觀察到該網(wǎng)站上所有用戶的行為，并能操控用戶訪問其他的惡意網(wǎng)站。
對于XSS漏洞，我們有兩種常見的措施，第一種就是消除漏洞，簡而言之就是在輸出頁面上不提供任何用戶的輸入信息；另外一種就是想辦法來抵御這種漏洞，可以采用對所有用戶的輸入編碼后再輸出（可以用OWASP的ESAPI），也可以對所有用戶輸入進行“白名單”驗證，另外，OWASP還提供了AntiSamy對HTML頁面做優(yōu)化以消除這個漏洞。
上面這段既包含了原理，也說了防止手段。算是我看過文章里比較全面的。那后邊我們進入最重點部分，那就是怎么去測試XSS跨站腳本攻擊。
大致上可以把XSS攻擊分成三類，Stored XSS、Reflected XSS、Dom-Base XSS。我們逐一介紹下。
首先是Stored XSS，就是存儲式跨站攻擊。這是最為厲害的一種攻擊方式，也是測試起來相對容易的。存儲式跨站攻擊簡單來說就是攻擊者提交給網(wǎng)站的數(shù)據(jù)呢會提交并永久保存到服務(wù)器的數(shù)據(jù)庫或者是文件系統(tǒng)等其他地方，之后不做任何編碼操作就會顯示在web頁面上。貌似說的不是很清楚，我們可以舉個例子來說：
比如說一個社交網(wǎng)站或其他可以給在網(wǎng)站中留言的地方，事實上呢，我們在可以留言的地方寫入一段代碼：
| <script>alert(document.cookie)</script> |
這樣這個信息就被存儲到了服務(wù)器上，當(dāng)有其他用戶訪問這個網(wǎng)頁時候，其瀏覽器就會執(zhí)行這個腳本，從而彈出一個關(guān)于cookie的alert。
我們就完成一次最簡單的存儲式跨站攻擊。到目前為止最典型的存儲式跨站攻擊的例子就是05年myspace發(fā)現(xiàn)的漏洞，具體情況大家自行g(shù)oogle~~~
其次Reflected XSS，反射跨站腳本攻擊。這個是最著名最常見的攻擊手段。所謂反射，就是等著服務(wù)器所給的返回。我們在進行測試行依據(jù)的就是在自己頁面上的簡單注入。在web客戶端提交了數(shù)據(jù)后，服務(wù)端馬上給這個請求生成返回結(jié)果頁，如果結(jié)果中包含了未驗證的客戶端輸入數(shù)據(jù)，那就表示會允許客戶端腳本直接注入到頁面里，也就出現(xiàn)了這樣一個漏洞。簡單舉個例子，在搜索引擎里邊，我們?nèi)绻阉髁艘粋€包含html代碼的字符串，如果返回的字符串仍然沒被編碼，那就是存在XSS漏洞了。呃，我自己說的也比較暈，不知道大家能理解沒有。
這個漏洞乍聽上去比較不嚴重，反正覺得只能在自己頁面上注入代碼嘛，但是其實只要有一些工程學(xué)方法，攻擊者就可以誘使其他用戶訪問一個在結(jié)果中注入了代碼的url，使攻擊者擁有整個頁面的權(quán)限。（具體的工程學(xué)方法。。我也不會，要是我會估計我就不在這里敲字了哈）
剛才說了三類，最后一類就是基于DOM的XSS攻擊。由于我是做web測試的，這類相對見的比較少，該漏洞多見于客戶端腳本，意思就是如果一個js訪問需要參數(shù)的url，并且需要把信息用于自己頁面，信息又未被編碼，就會出現(xiàn)該漏洞。是不是太抽象了？好吧，我簡化一下，我們是不是經(jīng)常看到一個網(wǎng)站（比如我們論壇）在網(wǎng)址后邊帶個參數(shù)（？XXX的），當(dāng)看到這種情況時候，我們可以在參數(shù)后邊加點料，加個<script></script>的，如果加了這個參數(shù)之后的結(jié)果不被編碼就輸出，那就證明它具有這么一個漏洞。
舉個例子吧，比如某某網(wǎng)站，我們輸入一個這樣的url去請求：
| http://server.com/XXX.php?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT> |
如果這個腳本被執(zhí)行了，那么我們就說他有這樣一個漏洞