PHP 防 SQL 注入實戰（三）：建立安全抽象層與改造現有應用

延續前兩篇關於注入類型與多查詢攻擊的分析，本文聚焦工程落地：如何通過抽象層封裝防護邏輯，以最小成本改造現有應用，構建可復用、可審計的安全防線。

為什麼需要安全抽象層？

在每個用戶輸入點手動調用轉義函數，不僅繁瑣易漏，更難保證團隊長期執行力。抽象層帶來三大核心收益：

1. 代碼本地化：所有防護邏輯集中在單一模組，修補漏洞只需改一處。
2. 查詢構造標準化：將轉義、引號包裹、類型檢查內建至工具函數，消除手寫 SQL 的隨意性錯誤。
3. 纵深防禦：結合最小權限原則，即使參數化查詢失效，抽象層仍能攔截惡意載荷。

輕量級抽象：安全查詢封裝函數

針對存量專案，最平滑的改造是引入 safe() 函數，封裝「加引號 + 實體轉義」：

function safe($string) {
    return "'" . mysql_real_escape_string($string) . "'";
}

// 使用範例
$variety = safe($_POST['variety']);
$query   = "SELECT * FROM wines WHERE variety=" . $variety;

攻擊場景模擬

惡意輸入：lagrein' or 1=1;

• 無防護：生成 WHERE variety = 'lagrein' or 1=1;' → 返回全表數據。
• 經 safe() 處理：生成 WHERE variety = 'lagrein\' or 1=1\;' → 單引號被轉義為字面量，查詢無結果，注入失敗。

進階抽象：資料庫存取類（DAO 模式）

對於新架構或重構專案，建議封裝 Database 類，內建參數化查詢支援：

class Database {
    private $pdo;
    public function __construct($dsn, $user, $pass) {
        $this->pdo = new PDO($dsn, $user, $pass, [
            PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
            PDO::ATTR_EMULATE_PREPARES => false, // 關鍵：使用真實預處理
        ]);
    }
    public function query($sql, array $params = []) {
        $stmt = $this->pdo->prepare($sql);
        $stmt->execute($params);
        return $stmt->fetchAll(PDO::FETCH_ASSOC);
    }
}

// 業務代碼極簡安全
$users = $db->query("SELECT * FROM users WHERE email = ? AND status = ?", [$email, 1]);

改造現有應用的實施路徑

1. 掃描入口：使用 grep -r "mysql_query\|mysqli_query" --include="*.php" 定位所有原始查詢點。
2. 分級替換：
   • 簡單查詢 → 替換為 safe() 包裹變量。
   • 複雜動態 SQL → 重構為參數化查詢或 Query Builder。
3. 統一接入：在公共引導文件（如 common.php）引入抽象層，禁用裸 mysql_* 函數。
4. 測試驗證：使用 SQLMap、OWASP ZAP 掃描驗證修復效果；單元測試覆蓋 safe() 邊界情況（NULL、陣列、編碼字符）。

避坑指南

• ❌ 不要 對已轉義字符串再次調用 safe()（雙重轉義）。
• ❌ 不要 在 LIKE 子句中直接使用 safe()，需額外轉義 %、_、\。
• ✅ 務必 設置資料庫連線字符集（SET NAMES utf8mb4），防止多字節編碼繞過轉義（如 GBK 雙字節攻擊）。
• ✅ 建議 為抽象層添加查詢日誌與慢查詢監控，兼顧安全與性能可觀測性。