一個優秀的PHP程序員除了要能順利的編寫代碼，還需要具備使程序處于安全環境下的能力。今天我們要向大家講解的是有關PHP防范SQL注入的相關方法。

說到網站安全就不得不提到SQL注入（SQL Injection），如果你用過ASP，對SQL注入一定有比較深的理解，PHP的安全性相對較高，這是因為MYSQL4以下的版本不支持子語句，而且當php.ini里的 magic_quotes_gpc 為On 時。

提交的變量中所有的 ' (單引號), " (雙引號), / (反斜線) and 空字符會自動轉為含有反斜線的轉義字符，給SQL注入帶來不少的麻煩。

請看清楚：“麻煩”而已~這并不意味著PHP防范SQL注入，書中就講到了利用改變注入語句的編碼來繞過轉義的方法，比如將SQL語句轉成ASCII編碼（類似：char(100,58,92,108,111,99,97,108,104,111,115,116…)這樣的格式），或者轉成16進制編碼，甚至還有其他形式的編碼，這樣以來，轉義過濾便被繞過去了，那么怎樣防范呢：

a． 打開magic_quotes_gpc或使用addslashes()函數

在新版本的PHP中，就算magic_quotes_gpc打開了，再使用addslashes()函數，也不會有沖突，但是為了更好的實現版本兼容，建議在使用轉移函數前先檢測magic_quotes_gpc狀態，或者直接關掉，代碼如下：

PHP防范SQL注入的代碼

復制代碼 代碼如下:

// 去除轉義字符  
function stripslashes_array($array) {  
if (is_array($array)) {  
foreach ($array as $k => $v) {  
$array[$k] = stripslashes_array($v);  
}  
} else if (is_string($array)) {  
$array = stripslashes($array);  
}  
return $array;  
}  
@set_magic_quotes_runtime(0);  
// 判斷 magic_quotes_gpc 狀態  
if (@get_magic_quotes_gpc()) {  
$_GET = stripslashes_array($_GET);  
$_POST = stripslashes_array($_POST);  
$_COOKIE = stripslashes_array($_COOKIE);  
}

去除magic_quotes_gpc的轉義之后再使用addslashes函數，代碼如下：

PHP防范SQL注入的代碼

復制代碼 代碼如下:

$keywords = addslashes($keywords);
$keywords = str_replace("_","/_",$keywords);//轉義掉”_”
$keywords = str_replace("%","/%",$keywords);//轉義掉”%”

后兩個str_replace替換轉義目的是防止黑客轉換SQL編碼進行攻擊。

b． 強制字符格式（類型）

在很多時候我們要用到類似xxx.php?id=xxx這樣的URL，一般來說$id都是整型變量，為了防范攻擊者把$id篡改成攻擊語句，我們要盡量強制變量，代碼如下：

PHP防范SQL注入的代碼

$id=intval($_GET['id']);

當然，還有其他的變量類型，如果有必要的話盡量強制一下格式。

c． SQL語句中包含變量加引號

這一點兒很簡單，但也容易養成習慣，先來看看這兩條SQL語句：

SQL代碼

復制代碼 代碼如下:

SELECT * FROM article WHERE articleid='$id'
SELECT * FROM article WHERE articleid=$id

兩種寫法在各種程序中都很普遍，但安全性是不同的，第一句由于把變量$id放在一對單引號中，這樣使得我們所提交的變量都變成了字符串，即使包含了正確的SQL語句，也不會正常執行，而第二句不同，由于沒有把變量放進單引號中，那我們所提交的一切，只要包含空格，那空格后的變量都會作為SQL語句執行，因此，我們要養成給SQL語句中變量加引號的習慣。

d.URL偽靜態化

URL偽靜態化也就是URL重寫技術，像Discuz！一樣，將所有的URL都rewrite成類似xxx-xxx-x.html格式，既有利于SEO，又達到了一定的安全性，也不失為一個好辦法。但要想實現PHP防范SQL注入，前提是你得有一定的“正則”基礎。