3.編碼原則

SQL注射是由于程序中對使用到的SQL沒有做到數據和結構分離導致程序的SQL能被惡意用戶控制，從而引發的數據庫信息泄漏，修改，服務器被入侵等一系列嚴重后果。

注入攻擊的本質，是把用戶輸入的數據當作代碼執行。這里有兩個關鍵條件，

1) 第一個是用戶能夠控制輸入 2) 第二個是原本程序要執行的代碼，拼接了用戶輸入的數據
 
 
4. SQL語法規范
1. 少用空值作為查詢條件。原因有兩個: 1) 空值將不能用上索引，會影響到數據庫性能，盡量在缺省值，在插入數據時自動讓數據庫填上缺省值 2) 容易產生空值永真、從而觸發攔截規則例：原語句： select * from employee where flag is null；改進后語句： select * from employee where flag=0(讓數據庫自動缺省為0)
 
2. 對數字型的SQL查詢采用明確的數字型強制類型轉換，原因有2點: 1) 原來的業務邏輯本身就是數字INT型，強制轉換后并不影響正常的業務 2) 對數字型的參數進行數字型強制類型轉換后，能防止攻擊者輸入除數字之外的額外的參數進行注入攻擊例:原語句：        $id = $_GET['id']; "select * from employee where id=$id"；改進后語句：        $id = intval($_GET['id']); "select * from employee where id=$id"；
 
3. 對字符型的SQL查詢采用對應編碼轉義操作，原因有2點: 1) 原來的業務邏輯本身就是純字符STRING型，轉義后不會影響到業務的運行 2) 對字符型的參數進行轉義后，能防止攻擊者輸入單引號、雙引號、反斜線等"閉合類字符"進行閉合注入，是一種有效防御注入的方法例:原語句：        $name = $_GET['name']; "select * from employee where name='$name'"；改進后語句：        $name = MySQL_real_escape_string($_GET['id']); "select * from employee where name=$name"；Ps: 1. 使用轉義函數的時候一定要注意當前腳本語言的編碼格式和數據庫的編碼格式是否一致，例如php和Mysql的編碼同時為GBK、或同時為UTF8時，轉義函數才能有效地對注入攻擊進行防御，否則存在被繞過的可能 2. 在連接數據庫的時候，需要執行以下語句，進行編碼統一: //例如你的數據庫采用的是GBK的編碼，則你的連接代碼應該寫成類似如下的格式 $mysqli = new mysqli("localhost", "root", "111", "test", 3306);$mysqli->set_charset('gbk'); //例如你的數據庫采用的是UTF8的編碼，則你的連接代碼應該寫成類似如下的格式 $mysqli = new mysqli("localhost", "root", "111", "test", 3306);$mysqli->set_charset('utf8');
 
4. 避免在SQL中出現永真永真條件常常被黑客用來進行注入探測，黑客可以利用永真條件的執行情況來判斷當前WEB應用是否存在被注入的可能性
 
5. 在SQL中強烈推薦使用參數化查詢對程序中使用到的SQL語句，使用變量綁定的方式進行數據和結構的分離是一種很好的防御SQL注入的方法  問題代碼示例： <?php    $id=$_GET['id'];    $conn = mysql_connect("localhost","root","") or die ("wrong!");    $sel=mysql_select_db("mydb",$conn);    $sql="select * from user where id = ".id    $que=mysql_query($sql,$conn); ?> 修復范例： <?php    $id=$_GET['id'];    $conn = mysql_connect("localhost","root","") or die ("wrong!");    $sel=mysql_select_db("mydb",$conn);    $sql="select * from user where id = :id" $stmt = $conn->PRepare($sql);     $stmt->execute(array(':id'=>$id)); ?>
 
 
 
5. 案例、場景
1. 不允許訪問系統表合理的SQL語句 1) select * from information_schema.COLUMNS;這條語句druid認為是合法的，因為這條語句沒有注入點的存在，SQL語句本身的唯一目的就是查詢系統表，說明用戶在進行正常的業務操作不合理的SQL語句 1) SELECT idFROM adminWHERE id = 1 AND 5 = 6 UNIONSELECT concat(0x5E252421, COUNT(8), 0x2A5B7D2F)FROM (SELECT `column_name`, `data_type`, `character_set_name`    FROM `information_schema`.`COLUMNS`    WHERE TABLE_NAME = 0x73696E6765725F616C62756D AND TABLE_SCHEMA = 0x796971696C61695F757466 ) t這條語句druid認為是非法的注入攻擊，因為SQL在子句(可能是注入點的地方)采取了union拼接，進行了連接系統表的查詢的操作
 
2. 不允許訪問系統變量合理的SQL語句 1) select @@basedir;這條語句druid不做攔截，因為這里沒有注入點的存在，也就不可能是黑客的注入攻擊，應該歸類于業務的正常需要不合理的SQL語句 2) SELECT * FROM cnp_news where id='23' and len(@@version)>0 and '1'='1' 這條語句druid會做攔截，攻擊者在子句中利用邏輯表達式進行非法的探測注入 
 
3. 不允許訪問系統函數合理的SQL語句 1) select load_file('//etc//passwd');druid不會攔截這條語句，還是同樣的道理，SQL注入的關鍵在于注入點，這條語句沒有注入點的存在，所以只能是用戶正常的業務需求不合理的SQL語句 1) select * from admin where id =(SELECT 1 FROM (SELECT SLEEP(0))A);   druid會智能地檢測出這個敏感函數出現在"where子句節點"中，而"where子句節點"經常被黑客用來當作一個SQL注入點，故druid攔截之
 
4. 禁止永真條件合理的SQL語句 1) 正常的業務語句SELECT F1, F2 FROM ADMIN WHERE 1 = 1;        -- 允許SELECT F1, F2 FROM ADMIN WHERE 0 = 0;        -- 允許SELECT F1, F2 FROM ADMIN WHERE 1 != 0;        -- 允許SELECT F1, F2 FROM ADMIN WHERE 1 != 2;        -- 允許不合理的SQL語句 1) 有攻擊性的SQL語句 select * from admin where id =-1 OR 17-7=10;  　    　　    -- 攔截 select * from admin where id =-1 and 1=2 -- 攔截 select * from admin where id =-1 and 2>1 -- 攔截 select * from admin where id =-1 and 'a'!='b' -- 攔截 select * from admin where id =-1 and char(32)>char(31)        -- 攔截 select * from admin where id =-1 and '1' like '1' -- 攔截 select * from admin where id =-1 and 17-1=10 -- 攔截 select * from admin where id =-1 and NOT (1 != 2 AND 2 != 2)    --攔截 select * from admin where id =-1 and id like '%%' -- 攔截 select * from admin where id =-1 and length('abcde') >= 5 -- 攔截
 
 
 
6. 技術FAQ
對任何防御系統來說，在有效攔截和誤攔截之前的分界線總是一個不斷優化的過程。因此，可能會出現一些本身正常的業務SQL語句，由于觸發了我們的攔截規則從而導致被誤攔截，以下列出一些可能會被攔截的SQL語句樣例：
1. 0x1 1) SQL語句SELECT COUNT( * ) FROM (SELECT header.id, header.tenant_id, header.create_date header_create_date, header.modify_date header_modify_date, header.supplier_id, header_detail.amount header_amount, header_detail.sku_id header_sku_idFROM purchase_order_header headerINNER JOIN purchase_order_detail header_detail ON ( header.id = header_detail.pid ) WHERE approve =1 )headerLEFT JOIN (SELECT arrive.id arrive_id, arrive.create_date arrive_create_date, arrive.modify_date arrive_modify_date, arrive_detail.qty arrive_qty, arrive_detail.sku_id arrive_sku_id, arrive.pid arrive_pidFROM purchase_arrive_order_header arriveINNER JOIN purchase_arrive_order_detail arrive_detail ON ( arrive.id = arrive_detail.pid ) WHERE approve =1 )arrive ON (header.id = arrive_pidAND header_sku_id = arrive_sku_id)LEFT JOIN (SELECT return_detail.amount return_amount, return_detail.qty return_qty, return_header.id return_id, return_header.tenant_id return_tenant_id, return_detail.sku_id return_sku_id, return_header.supplier_id return_supplier_id, return_header.create_date return_create_date, return_header.modify_date return_modify_dateFROM purchase_return_order_header return_headerINNER JOIN purchase_return_order_detail return_detail ON ( return_header.id = return_detail.pid ) WHERE approve =1 )return_header ON (tenant_id = return_tenant_idAND supplier_id = return_supplier_idAND return_sku_id = header_sku_id)WHERE 1 =1 OR header_modify_date >= '2014-03-13 07:53:30' OR arrive_create_date >= '2014-03-13 07:53:30' OR return_create_date >= '2014-03-13 07:53:30' OR header_modify_date < '2014-03-13 08:04:00' OR arrive_modify_date < '2014-03-13 08:04:00' OR return_modify_date < '2014-03-13 08:04:00' 2) 攔截原因WHERE 1=1的永真違反了規則 select alway true condition not allow
 
2. 0x2 1) SQL語句SELECT id, name, IFNULL( parentId, 0 ) parentId, isParentFROM goods_categoryWHERE companyId =17 UNION ALL SELECT 0 , '所有分類', NULL , NULL FROM dual 2) 攔截原因UNION ALL SELECT 0 , '所有分類', NULL , NULL FROM dual這句話違反了子查詢注入規則UNION ALL query not contains 'from clause'
 
3. 0x3:   DELETE FROM tds_permission; INSERT INTO tds_permission( id, name, memo, permission_key ) VALUES ( 1, '首頁', NULL , NULL ) , ( 2, '店鋪診斷', NULL , NULL ) , ( 3, '店鋪監控', NULL , NULL ) , ( 4, '訂單中心', NULL , NULL ) , ( 5, '營銷活動', NULL , NULL ) , ( 6, '促銷管理', NULL , NULL ) , ( 7, '客戶管理', NULL , NULL ) , ( 8, '系統管理', NULL , NULL ) ; DELETE FROM tb_role; INSERT INTO tb_role( id, name, memo ) VALUES ( 100000, '管理員', NULL ) , ( 100001, '普通用戶', NULL ); -- 角色_權限.普通用戶比管理員少一個"系統管理"權限DELETE FROM tb_role_permission; INSERT INTO tb_role_permission( role_id, permission_id ) VALUES ( 100000, 1 ) , ( 100000, 2 ) , ( 100000, 3 ) , ( 100000, 4 ) , ( 100000, 5 ) , ( 100000, 6 ) , ( 100000, 7 ) , ( 100000, 8 ) , ( 100001, 1 ) , ( 100001, 2 ) , ( 100001, 3 ) , ( 100001, 4 ) , ( 100001, 5 ) , ( 100001, 6 ) , ( 100001, 7 ) ; 2) 攔截原因 2.1) -- 角色_權限.普通用戶比管理員少一個"系統管理"權限: SQL語句中出現注釋 2.2) 一次SQL請求中包含了多條SQL語句，即堆疊查詢，這是黑客常用的攻擊方式