寬位元組XSS跨站攻擊
寬位元組跨站漏洞多發生在GB系統編碼。 對於GBK編碼，字元是由兩個位元組構成，在%df遇到%5c時，由於%df的ascii大於128，所以會自動拼接%5c，吃掉反斜線。而%27 %20小於ascii(128)的字元就會保留。通常都會用反斜線來轉義惡意字元串，但是如果被吃掉後，轉義失敗，惡意的xss程式碼可以繼續運行。
什麼是寬位元組
GB2312、GBK、GB18030、BIG5、Shift_JIS等這些都是常說的寬位元組，實際為兩位元組。（英文字母佔據一個位元組，漢字佔據兩個位元組）。寬位元組帶來的安全問題主要是吃ASCII字元（一位元組）的現象。
寬位元組SQL注入
先來複習下寬位元組注入的形成原理：
防禦方式：將 ‘ 轉換為 \'
繞過方式：將 \消滅
常規編碼
| 輸入 | 處理 | 編碼 | 帶入SQL | 結果 |
|---|---|---|---|---|
| ‘ | \' |
%5c%27 | id=1\' and |
不能注入 |
GBK編碼
MySQL在使用GBK編碼時，會認為兩個字元為一個漢字。
| 輸入 | 處理 | 編碼 | 帶入SQL | 結果 |
|---|---|---|---|---|
| %df’ | %df\' |
%df%5c%27（運） | id=運’ and | 能注入 |
兩個字元組合，認為是一個漢字
註：前一個ASCII碼大於128才能到漢字的範圍。
寬位元組XSS漏洞
寬位元組XSS與寬位元組SQL注入的不同在於寬位元組注入主要是通過
吃掉轉義符再正常注入SQL語句，而寬位元組XSS主要使用吃掉轉義符後注入惡意xss程式碼。
案例1：
一般情況下，當我們發現一個輸入框，想要插入xss程式碼在裡面：
<input type="text" id="name" value=""/>
通常做法是通過閉合前面的雙引號和注釋掉後面的雙引號來觸發
" /><script>alert(1)</script>//
但是開發人員一般為了防範我們在其中插入惡意程式碼，會在顯示之前使用過濾器對我們的輸入進行轉義，我們閉合使用的"被轉義為\",這樣就導致我們沒法閉合。
如果使用了GBK等編碼，我們就可以利用寬位元組xss。構造如下payload：
%c0%22 /><script>alert(1)</script>//
%c0和%df一樣，也是超出了GBK的範圍，此時在執行過濾操作時，源程式碼就變成了
<input type="text" id="name" value="%c0%5c%22 /><script>alert(1)</script>//">
當過濾器發現了%22，然後加入轉義（%5c）,但在解析的時候碰到%c0,於是%5c與%c0合併成一個特殊字元，我們的”得以保留。
<input type="text" id="name" value="%c0%5c%22 /><script>alert(1)</script>//">
下面是一個PHP的例子，在magic_quotes_gpc=On的情況下，如何處罰XSS？
<?php header("Content-Type: text/html;charset=GBK"); ?>
<head>
<title>gb xss</title>
</head>
<script> a="<?php echo $_GET['x'];?>";
</script>
我們會想到，需要使用閉合雙引號的方法：
gb.php?x=1";alert(1)//
在magic_quotes_gpc=Off 時源程式碼會變成：
<script> a="1";alert(1)//";</script>
由於magic_quotes_gpc=On，雙引號被轉義成\"導致閉合失敗
<script> a="1\";alert(1)//";</script>
由於網頁頭部指定了GBK編碼，GBK編碼第一位元組（高位元組）的範圍是0x81～0xFE，第二位元組（低位元組）的範圍是0x40～0x7E與0x80～0xFE。
gb.php?x=1%81";alert(1)//
此時當雙引號會繼續被轉義為\",最終程式碼如下：
<script> a="1[0x81]\";alert(1)//";</script>
[0x81]\ 組合成了一個合法字元，於是我們的被保留下來就會產生閉合，我們就成功觸發了xss。
GB2312是被GBK兼容的，它的高位範圍是0xA1～0xF7，低位範圍是0xA1～0xFE（0x5C不在該範圍內），把上面的PHP程式碼的GBK改為GB2312，在瀏覽器中處理行為同GBK，也許是由於GBK兼容GB2312，瀏覽器都做了同樣的兼容：把GB2312統一按GBK行為處理。
寬位元組注入防禦
1、使用utf-8，編碼寬位元組注入；
ps：不僅gbk，韓文、日文等都是寬位元組，都有可能存在寬位元組注入漏洞。
2、過濾客戶端提交的危險字元。
參考鏈接：
//blog.csdn.net/qq_29419013/article/details/81205291
//book.2cto.com/201301/14515.html
