PHP addslashes 與 SQL 注入防護：從基礎到最佳實務

addslashes() 曾是早期 PHP 防 SQL 注入的「萬靈丹」，但隨著資料庫驅動演進，**現代最佳實務已轉向參數化查詢（Prepared Statements）**。本文詳細說明 addslashes() 機制、侷限性、歷史誤區，並給出當前專案應採用的防注入標準流程。

一、addslashes() 基本機制

在**單引號 '、雙引號 \"、反斜線 \、NULL 字元**前加上反斜線跳脫。

$str = "Is your name O'reilly?";
echo addslashes($str); // Is your name O\'reilly?

反函數：stripslashes() 移除跳脫反斜線。

二、為何 addslashes() 不足以防 SQL 注入？

三、歷史誤區：magic_quotes_gpc

PHP < 5.4 曾有 magic_quotes_gpc=On 自動對 $_GET/POST/COOKIE 執行 addslashes，**已於 PHP 5.4 移除**。舊專案升級時務必檢查是否殘留 stripslashes() 邏輯導致資料遺失。

四、現代防注入黃金標準：參數化查詢

<?php
// PDO 範例（推薦）
$pdo = new PDO('mysql:host=127.0.0.1;dbname=test;charset=utf8mb4', 'user', 'pass', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false, // 使用真實預處理
]);

$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ? AND status = ?');
$stmt->execute([$email, 1]);
$user = $stmt->fetch();

// MySQLi 範例
$mysqli = new mysqli('127.0.0.1', 'user', 'pass', 'test');
$stmt = $mysqli->prepare('SELECT * FROM users WHERE email = ? AND status = ?');
$stmt->bind_param('si', $email, 1);
$stmt->execute();
$result = $stmt->get_result()->fetch_assoc();

五、輔助防護層（纏深防禦）

• 輸入驗證：型別、長度、格式、白名單（如 filter_var($email, FILTER_VALIDATE_EMAIL)）。
• 最小權限：資料庫帳號僅授予必要 SELECT/INSERT/UPDATE，拒絕 DROP/ALTER。
• 錯誤訊息不外露：生產環境關閉 display_errors，記錄至日誌。
• WAF/資料庫防火牆：雲端 WAF（Cloudflare、AWS WAF）或 ModSecurity 規則集。
• ORM/Query Builder：Laravel Eloquent、Doctrine、Yii ActiveRecord 內建參數化，杜絕手寫 SQL 拼接。

六、addslashes() 仍適用的少數場景

• **非 SQL 語境**需跳脫引號：如產生 JavaScript 字串常量 echo "var msg = '" . addslashes($msg) . "';"（更推薦 json_encode()）。
• **舊系統維護**無法引入參數化查詢時，搭配 mysqli_real_escape_string()（針對 MySQL 連線字元集）作為權宜之計。

七、htmlspecialchars() 與 addslashes() 差異

**總結**：新專案**全面採用參數化查詢**，addslashes() 退役為歷史教材；維護舊代碼時，識別其侷限並逐步重構為預處理語句。