前言

最近了解到安全公司的面試中都問到了很多關于SQL注入的一些原理和注入類型的問題，甚至是SQL注入的防御方法。SQL注入真的算是web漏洞中的元老了，著名且危害性極大。下面這里就簡單的分享一下我總結的四種SQL注入防御手段，加深理解，方便下次遇到這種問題時可以直接拿來使用。(主要是怕面試中腦殼打鐵，這種情況太常見了)

SQL注入占我們滲透學習中極大地一部分，擁有這很重要的地位。隨著防御手段的不段深入，市面上存在SQL注入的網站的確少之又少了，但不能說是沒有。在我看來，學習SQL注入的目的并不只是學習針對這種方法，而是一類方法，包括他的思想，思路和奇淫技巧，簡單點說就是舉一反三。學到現在發現好像越向后面學其他漏洞，方法思路都大體一致，比如字符串拼接，構造閉合語句，函數替代等等。

好了，說了這么多，現在我們步入正題吧！

我們簡單理解SQL注入就是在人為可以構造參數的地方加入一些非法敏感語句，繞過后端的處理，并帶入到數據庫中執行，然后返回敏感數據的過程。

限制數據類型

在傳入參數的地方限制參數的類型，比如整型 Integer，隨后加入函數判斷，如is_numeric($_GET[‘id’]) 只有當get到的id為數字或者數字字符時才能執行下一步，限制了字字符自然就限制了注入，畢竟構造參數怎么可能不傳入字符。但這種方法存在一定的限制，只能在特定的頁面才能使用，一般大部分都是要求我們傳入的字符串，但可以很大程度限制整型注入的情況。(針對此函數也是有一定繞過手段，比如轉為十六進制)

正則表達式匹配傳入參數

相信對于正則表達式大家都不陌生了，幾乎在過濾比較嚴格的地方都有正則表達式。(后面我也會寫一篇關于使用正則表達式的文章，包括基礎的使用和繞過)。這里簡單解讀一下這段正則表達式：

$id=$_POST['id'];
if (preg_match('/and|select|insert|insert|update|[A-Za-z]|/d+:/i', $id)) { 
        die('stop hacking!'); 
    } else {
        echo 'good'; 
    }

preg_match() 函數匹配傳入的id值，
/ 作為正則的起始標識符
| 代表或
[A-Za-z] 表示匹配參數中是否存在大小寫的26個字符
/d 匹配是否存在數字
+匹配一次或多次
/i 不區分大小寫

像下面這句：

?id=1’ union select 1,2# 因為匹配到union select，輸出 stop hacking!

正則表達式也具有一定危險性，在SQL注入繞過waf中談到過，正則表達式匹配非常消耗性能，因此攻擊時可以構造大量的正常語句‘騙’過服務器，當后臺對數據的處理達到最大限制時就會放棄匹配后面我們構造的非法語句，從而略過這個數據包。

函數過濾轉義

在php中最基本的就是自帶的magic_quotes_gpc函數，用于處理 ’ " 符號加上/ 防止轉義, 比如：

 ?id=1' and 1=1#  ===> ?id=1/' and 1=1#

另外還有addslashes(),也具有相同的效果。

像前面提到的**preg_match()**函數結合正則表達式或者黑名單也具有預防效果。

小tips：默認情況下，PHP 指令 magic_quotes_gpc 為 on，對所有的 GET、POST 和 COOKIE 數據自動運行 addslashes()。不要對已經被 magic_quotes_gpc 轉義過的字符串使用 addslashes()，因為這樣會導致雙層轉義。遇到這種情況時可以使用函數 get_magic_quotes_gpc() 進行檢測。

mysql_escape_string($string)：用反斜杠轉義字符串中的特殊字符，用于mysql_query()查詢。
mysql_real_escape_string() 函數轉義 SQL 語句中使用的字符串中的特殊字符。
轉義的符號包括 \x00 \n \r \ ’ " \x1a

預編譯語句

預編譯語句對現在的程序員來說基本都會去設計使用的方法，保障數據庫的安全。一般來說，防御SQL注入的最佳方式就是使用預編譯語句，綁定變量。

String query="select password from users where username='?' ";

下面講一下什么叫預編譯：使用預編譯相當于是將數據于代碼分離的方式，把傳入的參數綁定為一個變量，用？表示，攻擊者無法改變SQL的結構，在這個例子中，即使攻擊者插入類似 admin’ or 1=1# 的字符串，如果不做處理直接帶入查詢，那么query則變成了

query="select password from users where username='admin' or 1=1 ";

閉合了后面的引號，從而執行了惡意代碼。而預編譯則是將傳入的 admin’ or 1=1# 當做純字符串的形式作為username執行，避免了上面說到的SQL語句中的拼接閉合查詢語句等過程，可以理解為字符串與sql語句的關系區分開，username此時作為字符串不會被當做之前的SQL語句被帶入數據庫執行，避免了類似sql語句拼接、閉合等非法操作。就相當于拿著這個字符串去數據庫中找有沒有這個東西一樣。并且使用預編譯的SQL語句，SQL語句的語義不會發生改變。

下面給個php綁定變量的事例：

$query="INSERT INTO myCity (Name,CountryCode,District) VALUES (?,?,?)";
$stmt=$mysqli->prepare($query);
$stmt->bind_param("sss",$val1,$val2,$val3);
$val1="Stuttgart";
$val2="DEU";
$val3="Baden";
//execute the statement
$stmt->execute();

以上談到的四種方法都是一些基本方法，具體怎么實現防御還要看怎么去設計。說到預編譯語句是最佳方式，并不是說只是使用這一種方法就能夠防止SQL注入，而實際上預編譯也存在注入繞過的問題，并且也不是所有的地方都能夠使用預編譯語句。最佳的方式應該是多種方法結合，使用預編譯的同時還要加上其他函數過濾，正則匹配等，更多的還有根據實際情況自定義函數確保安全。

總結