Less-34
基於錯誤_POST_單引號_字符型_addslashes()_寬字節注入
《注入天書》中介紹因 POST 不能進行 URLencode，可使用 UTF-8 轉 UTF-16 或 UTF-32，實踐中發現正常的寬字節注入仍有效，猜測是編碼的問題，待解決。
一個參考：Unicode令人混淆的概念，編碼這種東西應該要系統地學習。
0x01. 寬字節注入
寬字節注入和 GET 中並無差別，原理在 Less 32 中已詳細介紹，使用%bb%27或%bb%5c%5c%27代替'均可，在這裏同樣可以平級越權：
uname=%bb' or 1 limit 1,1#&passwd=1
通過修改偏移limit可以平級越權得到其他賬號的回顯信息。
這裏的符號也可以換成 URL 編碼：#=%23，'=%27，(空格)=%20=+等。
已經繞過了addslashes()的過濾，確定了單引號閉合且無其他過濾，剩下的同 POST 最基本注入，可見 Less 11。
0x02. 編碼轉換注入
《注入天書》中，介紹了將 UTF-8 的'轉換爲 UTF-16 的�'實現注入的方法。這個字符我也不知道是什麼。
在Unicode和UTF編碼轉換網站上的轉換結果：
直接複製進 Burp：
注意：這裏的or 1是or 1=1的簡化寫法，只要是永真條件均可，同樣的還有or true、or 2>1等。
0x03. POST盲注
本關有正確回顯和錯誤回顯，且除了addslashes()無任何過濾，無論是 Bool 還是 Time 盲注都可以做到，參考前面的 POST 盲註腳本。
補充：
Unicode 是容納世界所有文字符號的國際標準編碼，使用四個字節爲每個字符編碼。
UTF 是英文 Unicode Transformation Format 的縮寫，意爲把 Unicode 字符轉換爲某種格式。UTF 系列編碼方案（UTF-8、UTF-16、UTF-32）均是由 Unicode 編碼方案衍變而來，以適應不同的數據存儲或傳遞，它們都可以完全表示 Unicode 標準中的所有字符。目前，這些衍變方案中 UTF-8 被廣泛使用，而 UTF-16 和 UTF-32 則很少被使用。
UTF-8 使用一至四個字節爲每個字符編碼，其中大部分漢字採用三個字節編碼，少量不常用漢字採用四個字節編碼。因爲 UTF-8 是可變長度的編碼方式，相對於 Unicode 編碼可以減少存儲佔用的空間，所以被廣泛使用。
UTF-16 使用二或四個字節爲每個字符編碼，其中大部分漢字採用兩個字節編碼，少量不常用漢字採用四個字節編碼。UTF-16 編碼有大尾序和小尾序之別，即 UTF-16BE 和 UTF-16LE，在編碼前會放置一個 U+FEFF 或 U+FFFE（UTF-16BE 以 FEFF 代表，UTF-16LE 以 FFFE 代表），其中 U+FEFF 字符在 Unicode 中代表的意義是 ZERO WIDTH NO-BREAK SPACE，顧名思義，它是個沒有寬度也沒有斷字的空白。
UTF-32 使用四個字節爲每個字符編碼，使得 UTF-32 佔用空間通常會是其它編碼的二到四倍。UTF-32 與 UTF-16 一樣有大尾序和小尾序之別，編碼前會放置 U+0000FEFF 或 U+FFFE0000 以區分。
待續。。。