淺談XSS攻擊的那些事（附常用繞過姿勢）

01-31

本文由geek痕?原創投稿一葉知安，已向作者發放一定獎勵。

投稿參見：一葉知安徵稿

前言

隨著互聯網的不斷發展，web應用的互動性也越來越強。但正如一個硬幣會有兩面一樣，在用戶體驗提升的同時安全風險也會跟著有所增加。今天，我們就來講一講web滲透中常見的一種攻擊方式：XSS攻擊。

什麼是XSS攻擊

先上一段標準解釋（摘自百度百科）。

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

相信以上的解釋也不難理解，但為了再具體些，這裡舉一個簡單的例子，就是留言板。我們知道留言板通常的任務就是把用戶留言的內容展示出來。正常情況下，用戶的留言都是正常的語言文字，留言板顯示的內容也就沒毛病。然而這個時候如果有人不按套路出牌，在留言內容中丟進去一行

<script>alert(「hey!you are attacked」)</script>n

那麼留言板界面的網頁代碼就會變成形如以下：

<html>n <head>n <title>留言板</title>n </head>n<body>n<div id=」board」 n <script>alert(「hey!you are attacked」)</script>n</div> n </body>n</html>n

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

XSS的危害

其實歸根結底，XSS的攻擊方式就是想辦法「教唆」用戶的瀏覽器去執行一些這個網頁中原本不存在的前端代碼。

可問題在於儘管一個信息框突然彈出來並不怎麼友好，但也不至於會造成什麼真實傷害啊。的確如此，但要說明的是，這裡拿信息框說事僅僅是為了舉個栗子，真正的黑客攻擊在XSS中除非惡作劇，不然是不會在惡意植入代碼中寫上alert（「say something」）的。

在真正的應用中，XSS攻擊可以乾的事情還有很多，這裡舉兩個例子。

竊取網頁瀏覽中的cookie值

在網頁瀏覽中我們常常涉及到用戶登錄，登錄完畢之後服務端會返回一個cookie值。這個cookie值相當於一個令牌，拿著這張令牌就等同於證明了你是某個用戶。

如果你的cookie值被竊取，那麼攻擊者很可能能夠直接利用你的這張令牌不用密碼就登錄你的賬戶。如果想要通過script腳本獲得當前頁面的cookie值，通常會用到document.cookie。

試想下如果像空間說說中能夠寫入xss攻擊語句，那豈不是看了你說說的人的號你都可以登錄（不過某些廠商的cookie有其他驗證措施如：Http-Only保證同一cookie不能被濫用）

劫持流量實現惡意跳轉

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

<script>window.location.href="http://www.baidu.com";</script>n

那麼所訪問的網站就會被跳轉到百度的首頁。

早在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=<imgnsrc=w.123 onerror=alert("hey!")>

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

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

<a onmousemove=』do something here』> n

當用戶滑鼠移動時即可運行代碼

<div onmouseover=『do something here』> n

當用戶滑鼠在這個塊上面時即可運行（可以配合weight等參數將div覆蓋頁面，滑鼠不划過都不行）

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

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

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

例如alert(1)編碼過後就是

alert(1)n

所以構建出來的攻擊語句如下：

http://192.168.1.102/xss/example5.php?name=<script>eval(alert(1))</script>

主動閉合標籤實現注入代碼

來看這份代碼：

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

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

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

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

效果如圖。

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

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

組合各種方式

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

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

XSS攻擊大致上分為兩類：

一類是反射型XSS，又稱非持久型XSS，
一類是儲存型XSS，也就是持久型XSS。

什麼是反射型XSS

其實，我們上面講XSS的利用手段時所舉的例子都是非持久型XSS。

也就是攻擊相對於訪問者而言是一次性的，具體表現在我們把我們的惡意腳本通過url的方式傳遞給了伺服器，而伺服器則只是不加處理的把腳本「反射」回訪問者的瀏覽器而使訪問者的瀏覽器執行相應的腳本。

也就是說想要觸發漏洞，需要訪問特定的鏈接才能夠實現。

什麼是儲存型XSS

它與反射型XSS最大的不同就是伺服器再接收到我們的惡意腳本時會將其做一些處理。

例如儲存到資料庫中，然後當我們再次訪問相同頁面時，將惡意腳本從資料庫中取出並返回給瀏覽器執行。這就意味著只要訪問了這個頁面的訪客，都有可能會執行這段惡意腳本，因此儲存型XSS的危害會更大。

還記得在文章開頭提到的留言板的例子嗎？那通常就是儲存型XSS。當有人在留言內容中插入惡意腳本時，由於伺服器要像每一個訪客展示之前的留言內容，所以後面的訪客自然會接收到之前留言中的惡意腳本而不幸躺槍。

這個過程一般而言只要用戶訪問這個界面就行了，不像反射型XSS，需要訪問特定的URL。

實例應用

1、劫持訪問

劫持訪問就是在惡意腳本中插入諸如的代碼，那麼頁面就會跳轉到百度首頁。

劫持訪問在持久型和非持久型XSS中都比較常被利用。持久型XSS中劫持訪問的危害不用說大家都清楚，但有人會問非持久型XSS中劫持訪問有什麼作用呢？

很簡單，試想下像http://qq.com，http://baidu.com這樣的域名下出現非持久型XSS，那麼在發送釣魚鏈接時就可以通過http://qq.com等域名進行跳轉，一般人一看到http://qq.com之類的域名警惕性會下降，也就更容易上當了。

2、盜用cookie實現無密碼登錄

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

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

（這裡以DVWA滲透測試平台為例）

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

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

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

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

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

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

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

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

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

3、配合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>n

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

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

效果看資料庫（密碼md5加密）

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

防範手段

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

首先是過濾。對諸如<script>、<img>、<a>等標籤進行過濾。
其次是編碼。像一些常見的符號，如<>在輸入的時候要對其進行轉換編碼，這樣做瀏覽器是不會對該標籤進行解釋執行的，同時也不影響顯示效果。
最後是限制。通過以上的案例我們不難發現xss攻擊要能達成往往需要較長的字元串，因此對於一些可以預期的輸入可以通過限制長度強制截斷來進行防禦。

後話

安全攻防雙方的博弈永遠都不會停止，也正是這種博弈推進了信息安全的發展。究竟是道高一尺還是魔高一丈很難定論。其實安全問題歸根結底還是一個信任的前提。什麼輸入值得信任？什麼輸入不值得信任需要特殊處理是安全人員常常要思考的一個問題。

（以上內容如有錯誤之處，敬請指正，謝謝！）

關於加入一葉之安讀者微信群的問題

我們開通了微信群後，有大量的讀者加入，現一群已滿，所以創建了二群，你還可以加微信：Guest_Killer_0nlis、cimoom829、Snake_90邀請進入。
Ps:已加入一群的小夥伴們就別再申請了^_^ 感謝大家的支持！

關於小密圈

前幾天，我們開設了『一葉知安小密圈』，為了避免潛水黨、醬油黨亂入，影響了整個學習、交流的氛圍。我們啟用了收費進入的方式。價格是小密圈最低定價 「50/人」。很快就有很多小夥伴加入，氛圍很好。附上部分截圖。

有想加入這個圈子的，可以掃描下方二維碼進入。