2012年8月19日 星期日

淺析XSS(Cross Site Script)漏洞原理


淺析XSS(Cross Site Script)漏洞原理

如果你還不知道什麼是XSS,那我來解釋一下,XSS的全稱是Cross Site Scripting,意思是跨站腳本.這第一個單詞是Cross,為什麼縮寫成X呢?因為CSS是層疊樣式表的縮寫(Cascading Style Sheets)的縮寫,同時Cross發音和X相似,為了避免混淆用X來代替,縮寫成XSS。其實我覺得叫XSS挺合適的,因為現在流行AJAX嘛,新的跨站腳本攻擊技術很多都是和XMLHTTP控制項無間配合,嘿嘿,這個是題外話,我們只講原理,下面我就分兩個部分分析XSS原理:

一、XSS的觸發條件

瞭解XSS的觸發條件就先得從HTML(超文字標記語言)開始,我們流覽的網頁全部都是基於超文字標記語言創建的,如顯示一個超連結:
    <A HREF="http://safe.it168.com">IT168安全頻道</A>

而XSS的原理也就是往HTML中注入腳本,HTML指定了腳本標記<script></script>.在沒有過濾字元的情況下,只需要保持完整無錯的腳本標記即可觸發XSS,假如我們在某個資料表單提交內容,表單提交內容就是某個標記屬性所賦的值,我們可以構造如下值來閉和標記來構造完整無錯的腳本標記,
    "><script>alert('XSS');</script><"

結果形成了<A HREF=""><script>alert('XSS');</script> <"">茄子寶的博客在這裡</A>這樣一個標記,這裡和SQL注入很像!

測試表單值所在的標記,形成完整無錯的腳本標記可觸發XSS,但是沒有腳本標記怎麼觸發XSS呢?呵呵,我們只好利用其他標記了,假如要在網頁裡顯示一張圖片,那麼就要使用一個<img>標記,示例如下:
    <img src=" http://safe.it168.com /xss.gif">

img標記並不是真正地把圖片給加入到Html文檔把兩者合二為一,而是通過src屬性賦值。那麼瀏覽器的任務就是解釋這個img標記,訪問src屬性所賦的值中的URL位址並輸出圖片。問題來了!瀏覽器會不會檢測src屬性所賦的值呢?答案是否!

那麼我們就可以在這裡大做文章了,接觸過javascript的人應該知道,javascript有一個URL偽協議,可以使用“javascript:”這種協議說明符加上任意的javascript代碼,當流覽器裝載這樣的URL時,便會執行其中的代碼.於是我們就得出了一個經典的XSS示例:
    <img src="javascript:alert('XSS');">

結果如圖一:
XSSIT16801.jpg

當然並不是所有標記的屬性都能用,細心的你應該發現標記的屬性在訪問檔才觸發的XSS,這裡我就不再深入,因為離開標記的屬性還有事件能説明我們觸發XSS.那什麼是事件呢?只有達到某個條件才會引發事件,正巧img標記有一個可以利用的onerror()事件,當img標記內含有一個onerror()事件而正好圖片沒有正常輸出便會觸發這個事件,而事件中可以加入任意的腳本代碼,其中的代碼也會執行.現在我們又得到了另外一個經典的XSS示例:
<img src=" http://xss.jpg" onerror=alert('XSS')>

結果如圖二:
XSSIT16802.jpg

綜合這一部分,我們知道XSS的觸發條件包括:完整無錯的腳本標記,訪問檔的標記屬性和觸發事件。

二、XSS轉碼引發的過濾問題

有攻就有防,網站程式師肯定不會放任大家利用XSS,所以他們常會過濾類似javascript的關鍵字符,讓大家構造不了自己的XSS,我這裡就撿兩個被忽略慣了的字元來說,它們是"&"和"\".首先來說說"&"字元,玩過SQL注入的都知道,注入的語句可以轉成16進制再賦給一個變數運行,XSS的轉碼和這個還真有異曲同工之妙,原因是我們的IE流覽器預設採用的是UNICODE編碼,HTML編碼可以用&#ASCII方式來寫,這種XSS轉碼支持10進制和16進制,SQL注入轉碼是將16進制字串賦給一個變數,而XSS轉碼則是針對屬性所賦的值,下面我就拿
<img src="javascript:alert('XSS');">

使用10進制轉碼來作範例:
<img src="&#106&#97&#118&#97&#115&#99&#114&#105&#112&#116&#58&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41&#59">

結果如圖三:
XSSIT16803.jpg

使用16進制轉碼來作範例:
<img src="&#x6a&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3a&#x61&#x6c&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29&#x3b">

這個&#分隔符號還可以繼續加0變成“&#0106” ,“&#00106” ,“&#000106” ,“&#0000106”等形式。

而這個"\"字元卻暴露了一個嚴重的XSS 0DAY漏洞,這個漏洞和CSS(Cascading Style Sheets)層疊樣式表有很大的關聯,下面我就來看看這個漏洞,先舉個javascript 的eval 函數的例子,官方是這樣定義這個函數:

eval(codeString),必選項 codestring 參數是包含有效 JScript 代碼的字串值。這個字串將由 JScript 分析器進行分析和執行。

我們的JavaScript中的"\"字元是轉義字元,所以可以使用"\"連接16進制字串運行代碼:

<SCRIPT LANGUAGE="JavaScript"> 
eval("\x6a\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3a\x61\x6c\x65\x72\x74\x28\x22\x58\x53\x53\x22\x29") 
</SCRIPT>

恐怖的是樣式表也支援分析和解釋"\"連接的16進制字串形式,流覽器能正常解釋。下面我們來做個實驗:

寫一個指定某圖片為網頁背景的CSS標記:

<html> 
<body> 
<style> 
BODY { background: url(http://127.0.0.1/xss.gif) } 
</style> 
<body> 
<html>

存檔為HTM,瀏覽器打開顯示正常。

轉換background屬性值為"\"連接的16進制字串形式,瀏覽器打開同樣顯示正常。

<html> 
<body> 
<style> 
BODY { background: \75\72\6c\28\68\74\74\70\3a\2f\2f\31\32\37\2e\30\2e\30\2e\31\2f\78\73\73\2e\67\69\66\29 } 
</style> 
<body> 
<html>

在文章第一部分我已經說過XSS的觸發條件包括訪問檔的標記屬性,因此我們不難構造出

<img STYLE="background-image: url(javascript:alert('XSS'))">
這樣的XSS語句。有了實驗的結果,我們又能對CSS樣式表的標記進行XSS轉碼,瀏覽器將幫我們解釋標記內容,XSS語法範例:
<img STYLE="background-image: \75\72\6c\28\6a\61\76\61\73\63\72\69\70\74\3a\61\6c\65\72\74\28\27\58\53\53\27\29\29">

結果如圖四:
XSSIT16804.jpg

原編者語:XSS攻擊以及的可怕性及靈活性深受駭客的喜愛。針對XSS攻擊,編者給一般瀏覽網頁使用者及WEB應用開發者給出以下的安全建議:

web使用者:

1.在電子郵件或者即時通訊軟體中點選連結時需要格外小心:留心可疑的過長連結,尤其是它們看上去包含了HTML代碼。如果對其產生懷疑,可以在流覽器位址欄中手工輸入功能變數名稱,而後通過該頁面中的連結瀏覽你所要的資訊。
2.對於XSS漏洞,沒有哪種web流覽器具有明顯的安全優勢。也就是Firefox也同樣不安全。為了獲得更多的安全性,可以安裝一些流覽器外掛程式:比如Firefox的NoScript或者Netcraft工具條。
3.世界上沒有“100%的有效”。儘量避免訪問有問題的網站:比如提供hack資訊和工具、破解軟體、成人照片的網站。這些類型的網站會利用瀏覽器漏洞並危害作業系統。

web應用開發者:

1.對於開發者,首先應該把精力放到對所有使用者提交內容進行可靠的輸入驗證上。這些提交內容包括URL、查詢關鍵字、http頭、post資料等。只接受在你所規定長度範圍內、採用適當格式、你所希望的字元、阻檔、過濾或者忽略其它的任何東西。
2.保護所有敏感的功能,以防被bots自動化或者被協力廠商網站所執行。實現session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查。
3.如果你的web應用必須支援用戶提供的HTML,那麼應用的安全性將受到災難性的下滑。但是你還是可以做一些事來保護web網站:確認你接收的HTML內容被妥善地格式化,僅包含最小化的、安全的tag(絕對沒有JavaScript),去掉任何對遠端內容的引用(尤其是樣式表和JavaScript)。為了更多的安全,請使用httpOnly的cookie。

轉載自《網路攻防戰》