Nginx 防禦 SQL 注入攻擊實戰設定指南

Nginx 層面防禦 SQL 注入的實作策略

雖然最根本的防禦應在應用程式層對所有輸入資料進行過濾與轉義，但在 Web 伺服器層面增加一道防線同樣重要。本文介紹如何利用 Nginx 的 rewrite 與 $query_string 變數，攔截包含高風險特殊字元的請求，降低 SQL 注入風險。

核心概念：URI 與 Query String 的區別

• URI：URL 中 ? 之前的部分（如 /plus/list.php），可直接用 rewrite 正則比對。
• Query String：URL 中 ? 之後的參數部分（如 tid=19&mid=1124'），Nginx 中以 $query_string 變數取得，無法在 rewrite 中直接比對，需搭配 if 判斷。

錯誤示範：直接用 rewrite 比對參數

# 錯誤寫法：rewrite 只比對 URI，無法攔截參數中的單引號
rewrite ^.*([\;'\<\>]).* /error.html break;

上述規則只會檢查 /plus/list.php，完全忽略 tid=19&mid=1124' 中的惡意字元。

正確作法：搭配 $query_string 與 if 判斷

# 在 server 或 location 區塊中加入
if ($query_string ~* ".*[\;'\<\>].*") {
    return 404;
}

• ~*：不區分大小寫的正則比對
• [\;'\<\>]：比對分號、單引號、尖括號等高風險字元
• return 404：直接回傳 404 隱藏伺服器資訊，避免攻擊者探測

進階防護建議

1. 擴充特殊字元清單：可加入 union、select、drop、-- 等 SQL 關鍵字（需謹慎避免誤判正常流量）。
2. 結合 WAF 模組：生產環境建議部署 ModSecurity 或 Nginx WAF（如 ngx_waf、openresty + lua-resty-waf），提供更完整的規則集與日誌審計。
3. 應用層防禦不可省略：參數化查詢、ORM 框架、輸入驗證、最小權限資料庫帳號才是根本之道。

適用場景與限制

結論：Nginx 層面過濾可攔截自動化掃描工具與低階攻擊，但絕不可作為唯一防禦手段。請務必在應用程式實作參數化查詢與完整輸入驗證。