Bugku上看到一道這方面的題，從網上看了不少資料，談一談自己的認識。

               當我們在位址列輸入單引號時頁面並沒有報錯，

        說明單引號應該被過濾了，轉義為 \'  防止注入 

                檢視原始碼

                     字元編碼為gb2312   

            注意： html中的編碼並不影響測試，本題應該是作為提示。 html編碼改成utf-8依然會實現注入

      字元編碼為gb2312  該編碼存在注入漏洞   可以繞過  \' 過濾

      儘管現在呼籲所有的程式都使用unicode編碼，所有的網站都使用utf-8編碼，來一個統一的國際規範。但仍然有很多，包括國內及國外（特別是非英語國家）的一些cms，仍然使用著自己國家的一套編碼，比如gbk，作為自己預設的編碼型別。

通常來說，一個gbk編碼漢字，佔用2個位元組。一個utf-8編碼的漢字，佔用3個位元組。

GBK 向下與 GB 2312 相容 ，可以理解為gbk是gb2312的擴充套件版本 。編碼漢字時16進位制範圍可能不同。

gbk 首位元組對應0×81-0xFE，尾位元組對應0×40-0xFE（除0×7F），剛好涵蓋了轉義符號\對應的編碼0×5C。

0xD50x5C 對應了漢字“誠”，URL編碼用百分號加字元的16進位制編碼表示字元，於是 %d5%5c 經URL解碼後為“誠”。

例如: 構造攻擊

    url提交為：www.baidu.com/test.php?username=aaa&passwrod=bbb %d5屬於首位元組大於128 可以構造範圍內的任意ascii碼

    www.baidu.com/test.php?username=aaa%d5' %20or%201=1%23&password=bbb      %20為空格 %23為註釋符號#號            

    url解碼後 username=aaa 0xd5 0×27 0×20 or 0×20 1=1 0×23

    資料庫呼叫過濾函式轉義字元單引號0x27 變成0x5c0x27 0x5c為 / 字元

    gbk編碼 0x5c0x27被認為是一個漢字 誠

強調一下 只要是前一個字元為大於(ascii碼)128即可 0x5c被通用 可以構造不同的16進位制

此時 查詢語句就為 select * from user where username=aaa誠' or 1=1 #&password=bbb

即 select * from user where username=aaa誠' or 1=1 永真 成功注入

當然 utf-8編碼不會出現這種情況 字元範圍和位元組數不同

我們再看sql注入這道題

當我們在url輸入 %df' 時頁面報錯

繁體字被寫入語句 所以開始構造，我們首先order by

頁面正常

繼續

開始聯合查詢

庫名為sql5 繼續聯合查詢

得到flag ！