PHP 防範 SQL 注入的完整防禦指南（實測有效）

為什麼 SQL 注入仍是關鍵議題？

雖然 PHP 內建 magic_quotes_gpc 會自動轉義單引號、雙引號與反斜線，但駭客可透過編碼繞過（如 ASCII、十六進制編碼），單靠預設防護遠遠不夠。優秀的 PHP 開發者必須建立多層次防禦體系。

核心防禦策略

a. 統一輸入轉義流程

建議關閉 magic_quotes_gpc，改由應用層集中處理：

// 移除舊版自動加上的反斜線
function stripslashes_array($array) {
    if (is_array($array)) {
        foreach ($array as $k => $v) {
            $array[$k] = stripslashes_array($v);
        }
    } elseif (is_string($array)) {
        $array = stripslashes($array);
    }
    return $array;
}

@set_magic_quotes_runtime(0);
if (@get_magic_quotes_gpc()) {
    $_GET    = stripslashes_array($_GET);
    $_POST   = stripslashes_array($_POST);
    $_COOKIE = stripslashes_array($_COOKIE);
}

再以 addslashes() 統一轉義，並針對 _、% 等萬用字元額外處理：

$keywords = addslashes($keywords);
$keywords = str_replace('_', '\\_', $keywords);
$keywords = str_replace('%', '\\%', $keywords);

b. 強制型別轉換

對預期為整數的參數（如 id），直接轉型：

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

其他型別同理，盡早鎖定資料格式。

c. SQL 語句中變數務必加引號

// 安全：變數被視為字串
SELECT * FROM article WHERE articleid = '$id'

// 危險：若 $id 為 "1 OR 1=1" 將改變邏輯
SELECT * FROM article WHERE articleid = $id

養成「所有變數入 SQL 必須用單引號包裹」的習慣。

d. URL 偽靜態化（Rewrite）

將動態參數隱藏於靜態化路徑（如 article-123.html），配合正則路由，可同時兼顧 SEO 與安全性，增加注入難度。

進階建議：使用預處理語句

現代專案應優先採用 PDO 或 MySQLi 的預處理語句，從根本上分離程式碼與資料，徹底杜絕注入風險。