寬位元組XSS跨站攻擊

寬位元組跨站漏洞多發生在gb系統編碼。對於gbk編碼，字元是由兩個位元組構成，在%df遇到%5c時，由於%df的ascii大於128，所以會自動拼接%5c，吃掉反斜線。而%27 %20小於ascii(128)的字元就會保留。通常都會用反斜線來轉義惡意字串，但是如果被吃掉後，轉義失敗，惡意的xss**可以繼續執行。

gb2312、gbk、gb18030、big5、shift_jis等這些都是常說的寬位元組，實際為兩位元組。（英文本母佔據乙個位元組，漢字佔據兩個位元組）。寬位元組帶來的安全問題主要是吃ascii字元（一位元組）的現象。

先來複習下寬位元組注入的形成原理：

防禦方式：將 ' 轉換為\'

繞過方式：將\消滅

常規編碼

輸入處理

編碼帶入sql結果'

\'

%5c%27

id=1\'and

不能注入

gbk編碼

mysql在使用gbk編碼時，會認為兩個字元為乙個漢字。

輸入處理

編碼帶入sql

結果%df'

%df\'

%df%5c%27（運）

id=運' and

能注入兩個字元組合，認為是乙個漢字

注：前乙個ascii碼大於128才能到漢字的範圍。

寬位元組xss與寬位元組sql注入的不同在於寬位元組注入主要是通過

吃掉轉義符再正常注入sql語句，而寬位元組xss主要使用吃掉轉義符後注入惡意xss**。

案例1：

一般情況下，當我們發現乙個輸入框，想要插入xss**在裡面：

通常做法是通過閉合前面的雙引號和注釋掉後面的雙引號來觸發

" />//

但是開發人員一般為了防範我們在其中插入惡意**，會在顯示之前使用過濾器對我們的輸入進行轉義，我們閉合使用的"被轉義為\",這樣就導致我們沒法閉合。

如果使用了gbk等編碼，我們就可以利用寬位元組xss。構造如下payload：

%c0%22 />//

%c0和%df一樣，也是超出了gbk的範圍，此時在執行過濾操作時，源**就變成了

//">

當過濾器發現了%22，然後加入轉義（%5c）,但在解析的時候碰到%c0,於是%5c與%c0合併成乙個特殊字元，我們的"得以保留。

//">

案例二：

下面是乙個php的例子，在magic_quotes_gpc=on的情況下，如何觸發xss？

<?php header("content-type: text/html;charset=gbk"); ?> 
gb xsstitle> 
head> 
a="<?php echo $_get['x'];?>"; 
script>

我們會想到，需要使用閉合雙引號的方法：

gb.php?x=1";alert(1)//

在magic_quotes_gpc=off 時源**會變成：

由於magic_quotes_gpc=on，雙引號被轉義成\"導致閉合失敗

由於網頁頭部指定了gbk編碼，gbk編碼第一位元組（高位元組）的範圍是0x81～0xfe，第二位元組（低位元組）的範圍是0x40～0x7e與0x80～0xfe。

gb.php?x=1%81";alert(1)//

此時當雙引號會繼續被轉義為\",最終**如下：

[0x81]\ 組合成了乙個合法字元，於是我們的"被保留下來就會產生閉合，我們就成功觸發了xss。

gb2312是被gbk相容的，它的高位範圍是0xa1～0xf7，低位範圍是0xa1～0xfe（0x5c不在該範圍內），把上面的php**的gbk改為gb2312，在瀏覽器中處理行為同gbk，也許是由於gbk相容gb2312，瀏覽器都做了同樣的相容：把gb2312統一按gbk行為處理。

1、使用utf-8，編碼寬位元組注入；

ps：不僅gbk，韓文、日文等都是寬位元組，都有可能存在寬位元組注入漏洞。

2、過濾客戶端提交的危險字元。

寬位元組XSS跨站攻擊

跨站指令碼攻擊 XSS

Xss跨站指令碼攻擊

xss 跨站指令碼攻擊

寬位元組XSS跨站攻擊

跨站指令碼攻擊 XSS

Xss跨站指令碼攻擊

xss 跨站指令碼攻擊

相關推薦