SQL注入（寬位元組注入、長字符截斷）

本文僅記錄SQL注入漏洞學習程序中的基本知識，
SQL注入漏洞是完全可以避免的安全問題，從其形成原因來看，就是用戶輸入的資料（可能帶有惡意）被SQL解釋器當作代碼執行，從而獲得更多資料庫的資訊或者獲得更高的權限，從原理上來說，SQL注入可以分為兩大類，數字型注入；字串型注入；（《web安全深度剖析 張炳帥》），

數字型注入

即輸入型別為int型別，如ID，年齡，頁碼等，一般來說，數字型注入只存在于弱型別陳述句中，如：PHP,ASP，python，而對于C，java等強型別語言則不存在，弱型別語言會自動判斷變數型別，從程式員角度來說，這提供了很大的便利，但從安全角度來說，也帶來了安全隱患，比如，id=8，弱語言會將id判斷為int型別；而id= 8 and 1=1,則會判斷為字串型string，這為注入提供了可能，對于強型別語言，由于必須提前宣告變數型別，賦值型別錯誤則會拋出例外，

字符型注入

輸入型別為字串時，稱為字符型注入，字符型與數字型的最大區別就是字符型需要使用單引號來閉合，如：

select * from table where id = 8  //數字型注入
select * from table where usename = 'admin' //字符型注入

對于字符型注入，關鍵的是輸入的閉合及多余部分的注釋，對于Mysql來說，共有三種注釋方式：

(1) select * from stu -- 注釋  //注釋時，–與注釋之間必須要一個空格,注意stu與--之間必須有空格，--與注釋之間也必須有空格
(2) select * from stu #注釋  //使用#對格式要求不高，stu與#，#與注釋之間均不需要空格，當然為了格式，也可以留有空格
(3) select * from stu /*注釋*/  //(1)(2)為單行注釋，(3)為多行注釋，留不留空格均可,使用此需要注意

嚴格來說，數字也是字串，查詢時where id = 8 與 where id = '8’均可，通常在數字查詢時，不加單引號，

更細致的分類，如 POST注入、cookie注入、盲注、延時注入等，均是根據注入位置不同，對字符型注入和數字型注入的具體叫法，

POST注入：注入欄位位于POST資料中；
Cookie注入：注入欄位位于cookie資料中；
延時注入：使用資料延時特點注入；
搜索注入：注入處為搜索地點；
base64注入：注入欄位經Base64編碼；

mysql中的注入問題：

注釋問題

由于使用的是kali linux,默認安裝的是mariaDB，兩者基本兼容，關于兩者的歷史淵源及對比，文末給出參考鏈接，對于mysql中三種注釋方式，多行注釋/* */需要補充說明：

select * from user;  #正常讀取表user的所有列內容
select user from user;  #讀取user列的內容
select user /* */ from user;  #此處/* */為注釋，對陳述句不產生影響，mysql陳述句以‘;’為陳述句結束標志
select user /*!,password*/ from user;  #此處并不是注釋，注意'!'的使用

需要特別注意的是 **select user /!,password/ from user;**此陳述句中/!,password/ 被正常執行，’!'具有特殊意義，它代表著條件判斷，其后如果加上條件，則必須為版本號，如
/!100324,password/ 表示如果版本號高于或等于10.03.24時，其后的陳述句才會被執行，如果像上述不加條件，則陳述句直接執行，如下：

select version();  #查詢版本號，版本號為10.3.24
select user /*!100324,password*/ from user;  #版本號需要變為10.03.24
select user /*!100325,password*/ from user;  #當版本號高于10.03.24時，陳述句不會執行

寬位元組注入

在PHP5.4以前，組態檔php.ini中，存在設定：magic_quotes_gpc ,默認情況下，其處于開啟狀態（On)時,使用 G E T 、 GET、 GET、POST、$Cookie,會對特殊字符單引號(’)、雙引號(")、反斜線()、空字符( NULL)進行轉義防止SQL注入危險，但是在PHP5.4版本后，洗掉了這一選項，即默認其為關閉狀態（Off），則需要通過如addslashes，mysql_real_escape_string等函式對危險字符進行轉義，
如下，php版本為7.4，默認關閉狀態，在test.php中輸入以下陳述句：

<?php 
echo "<h3> input: ". $_GET['id'] ."</h3>"; 
?>

在firefox中輸入網址：https://127.0.0.1/test.php?id=%3c%27,結果如下：

可見，其并沒有對危險字符(’)進行轉義，關于apache+php的搭建，這里不做詳細敘述了，

寬位元組注入原理 ：所謂的寬位元組，實際上就是兩位元組，在轉換編碼的程序中，將單位元組的編碼結合其后的編碼看做兩位元組，即 將兩個字符誤認為是一個寬字符而解碼，
下面結合具體的例子對其說明：
在檔案夾相應位置有t.php檔案：

<?php 
header("Content-type: text/html; charset=gb2312");
//header("Content-type: text/html; charset=utf-8");
if (!empty($_GET['id']))
    {
        $input  = addslashes($_GET['id']);
        //addslashes()回傳在預定義的字符（即上述四種特殊字符）前添加反斜杠的字串，
    }
echo "<h3> input:". $input."</h3>"; 
?>

補充說明：utf-8為單位元組編碼，GBK(gb2312)為寬位元組編碼，如果采用utf-8編碼，則不會出現寬位元組注入，
打開firefox瀏覽器，輸入：https://127.0.0.1/t.php?id=%27，出現以下回傳結果：

此時，單引號被轉義，輸入：https://127.0.0.1/t.php?id=%d5%27，此時：

發現單引號并沒有被轉義，就此分析：
(1).瀏覽器輸入id=%d5%27
(2).通過GET方式獲取到資料，進行判斷輸入資料中是否存在預定義字符，發現存在單引號，愉快的將其轉換為’, 同時對其編碼，此時id=%d5%5c%27(\對應的編碼為%5c),準備回傳資料
(3).接收端對其解碼，首先對%d5進行GBK解碼，發現無對應字符，再對%d5%5c解碼，發現正好對應一個漢字，快樂的解碼了，結果留下%27，被解碼成單引號，相當于沒轉義
相應的編碼如下：（編碼解碼工具）



注：mysql及php默認采用的是utf-8編碼，即單字符編碼，此時不會產生寬字符注入；在php中使用GB2312、GBK、GB18030、BIG5、Shift_JIS等編碼方式時，即采用寬位元組，此時要注意安全問題，

mysql長字符截斷

mysql中有一個環境變數配置sql_mode,定義了mysql應該支持的sql語法，資料校驗等,可以通過以下方式查看當前資料庫使用的sql_mode：

select @@sql_mode

具體的引數解釋見參考資料5：MySQL的sql_mode模式，mysql5.0版本以上支持了三種sql_mode模式，如下：

默認情況下，mysql選擇使用的是嚴格模式，此時如果插入的資料超過限制長度，則會報錯error(如果超出的長度是由空格引起的，可能只會警告warning，實際操作證明，三種模式下，如果插入的超出長度是由空格引起的，并不會報錯，僅僅會警告，本節最后給出結果):

describe users;
insert into users values (1,'admin','123');#正常插入
insert into users values (2,'admin   ','123');
#username限制7個字符，這里插入8個字符（后3個為空格，插入成功，出現警告），出現截斷情況
insert into users values (3,'admin   x','1234');#報錯，提醒超長字符

對于id=2的插入，可以查看其usernsme的長度,發現其長度為7:

select length(username) from users where id = 2;

下面重點討論當sql_mode模式為ANSI時引起的長字符截斷問題：
首先將sql_mode設定為ANSI模式：

SET @@sql_mode=ANSI;

接下來依次創建table,插入資料，這里發現username='admin x’也插入成功了：

create table users(
    -> id int(11) NOT NULL,
    -> username varchar(7) NOT NULL,
    -> password varchar(12) NOT NULL);#創建users表格
insert into users values (1,'admin',123);#正常插入
insert into users values (2,'admin   ',1234);#警告，插入成功
insert into users values (3,'admin  x',12345);#警告，插入成功

觀察一下各個用戶的長度，可以發現id=2,id=3的username均被截斷，長度都變成了7：

select *from users;
select length(username) from users where id =1;
select length(username) from users where id =2;
select length(username) from users where id =3;

如果此時選擇username= 'admin’會出現下面情況：

select username from users where username = 'admin';

此時，我們只查詢了用戶名為admin的用戶，但另外兩個長度不一致的用戶卻出現，這會造成安全問題，假如，某個管理員的用戶名就是admin,他采用下面的陳述句登錄：
$sql = "select count ( * ) from users where username = ‘admin’ and password = ‘*****’ ";
此時，我們只要偽造用戶’admin x’便可以獲得管理員的資訊，從而進入后臺，

補充： 對于三種模式下的空格插入溢位，并不會報錯，結果如下：

SET @@sql_mode=STRICT_TRANS_TABLES;
insert into users values (4,'admin     ',12345);
insert into users values (5,'admin     x',12345);

SET @@sql_mode=TRADITIONAL;
insert into users values (6,'admin     ',123456);
insert into users values (7,'admin     x',123456);

由此可見，預防長字符截斷問題可能需要從其他地方入手，如賬號由管理員分配并限制更改；對資料庫內容加密，即使獲取到相關資訊也無法破解，

延時注入

延時注入屬于盲注的一種，所謂盲注，即頁面無差異注入，延時注入基于時間差異技術，需要使用到資料庫的相關函式，在此僅作原理上的說明，
在mysql中存在函式sleep(time)，即在給定的時間tine(s)后才會執行對應的陳述句，如：
http://www.abc.com/user.php?id=1 and sleep(3) //頁面回傳正常，3秒后才打開
此時，則可以確定用戶輸入的資料被當作陳述句執行了，則存在SQL注入漏洞，結合其他函式則可以獲取用戶資訊，思路是：首先判斷用戶名長度，再截取字串第一個字符轉換成ASCII碼，對比ASCII表，獲得資訊，接著回圈判斷便可以獲得用戶名 ，這里不具體說明了，

參考資料：

1. MariaDB和MySQL全面對比：選擇資料庫需要考慮這幾點
2. SQL注入教程——（四）寬位元組注入
3. PHP安全轉義函式詳解
4. Kali安裝Apache、MySQL、PHP
5. MySQL的sql_mode模式