一個優秀的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注入，前提是你得有一定的“正則”基礎。
