以 AWS WAF 強化 Web 安全：SQL Injection 攻擊原理與防禦實作

SQL Injection 與防禦定位：注入風險與 WAF 的角色

什麼是SQL？什麼是SQL Injection？

SQL（Structured Query Language）是一種用於操作關聯式資料庫的標準語言，常用於查詢、寫入、更新與刪除資料。多數 Web 應用會透過後端程式動態組合 SQL，與資料庫進行資料互動。

SQL Injection（SQL 注入，或稱資料隱碼攻擊）則是一種利用應用程式輸入處理不當的攻擊手法。當應用程式以字串拼接方式產生 SQL 查詢時，攻擊者可透過輸入欄位插入惡意語句，改變原本查詢邏輯，進而繞過驗證、存取未授權資料，甚至破壞資料庫內容。
其核心原理在於：當後端未妥善過濾輸入或未使用參數化查詢時，資料庫無法區分「正常輸入」與「惡意指令」，最終將其一併解析並執行，導致非預期結果。

隨著資料庫技術與攻擊工具發展，SQL Injection 已衍生多種形式，常見類型包括：

基本 SQL 注入（Classic SQL Injection）：透過改寫查詢條件（如永真條件）繞過驗證。
UNION 查詢注入（UNION-based SQL Injection）：利用 UNION 合併查詢取得額外資料。
錯誤型注入（Error-based SQL Injection）：透過資料庫錯誤訊息推測結構。
盲注（Blind SQL Injection）：透過回應差異或時間延遲推測結果。
堆疊查詢注入（Stacked Queries SQL Injection）：一次執行多條 SQL 指令。
過程注入（Stored Procedure Injection）：濫用儲存程序執行惡意操作。

然而，從風險角度來看，SQL 注入具備低門檻、高破壞力的特性：攻擊成本低，但可能導致資料外洩、資料破壞、系統遭入侵與合規風險等多重損失。

攻擊階段	直接損失	間接損失	修復成本
信息洩露	用戶、業務數據遭竊取	品牌聲譽受損、客⼾流失	數據恢復、通知用戶費用
數據破壞	數據庫被刪除或加密（勒索）	業務停擺、收⼊中斷	備份恢復、系統重建時間
後續滲透	伺服器控制權遭奪取	成為攻擊跳板、法律⻛險	全面安全檢查與清毒
合規處罰	GDPR 或等保合規罰款	失去客⼾與合作夥伴信任	合規改造、認證重新審計

AWS WAF 的角色：HTTP 流量層的安全控管

AWS WAF（網路應用防火牆，Web Application Firewall）用於監控並過濾進入 Web 應用與 API 的 HTTP/HTTPS 請求。它可依規則對流量執行允許、封鎖或記錄，並部署於 CloudFront、Application Load Balancer（ALB）與 API Gateway 前端，在請求進入後端前完成檢測與過濾。

然而，在 SQL Injection 防護上，AWS WAF 透過規則與特徵比對檢測請求內容（如 Query、Body、Header、Cookie 等），即時阻擋常見攻擊（如 SQL Injection、XSS）。實務上可直接套用 AWS Managed Rules 建立基礎防護，於攻擊進入應用前攔截請求，降低漏洞被利用風險，並與程式層防護形成分層防禦。

在理解 AWS WAF 的防護定位後，接下來可從實際攻擊流程觀察 SQL Injection 如何發生，以及 WAF 如何在真實場景中發揮作用。
以下將以簡單登入驗證場景為例，說明 SQL Injection 的實際運作方式與測試流程。

延伸閱讀：AWS WAF 是什麼？功能、定價與 DDoS 防禦完整指南

SQL Injection 實際演示流程

在典型 Web 架構（前端 → 後端 → 資料庫）中，登入功能通常會將使用者輸入組合成 SQL 查詢並送往資料庫執行。
SQL Injection 的核心在於「字符串拼接」的邏輯缺陷。若以後端視角理解 SQL Injection 攻擊原理，典型登入驗證大致如下：

與資料庫比對後回傳結果並完成登入
使用者於 Web 頁面輸入帳號與密碼
後端接收輸入並組合 SQL 查詢

以下以國際開源測試項目 OWASP Juice Shop 為例，項目地址是 https://github.com/juiceshop/juice-shop.git

此程式以字串拼接產生查詢語句，未對輸入進行驗證或參數化處理，因而存在注入風險。
query = f”SELECT * FROM users WHERE username='{username}’ AND password='{password}'”

當輸入正常帳密（如 admin / admin123）時，查詢為：
SELECT * FROM users WHERE username=’admin’ AND password=’admin123′

但若攻擊者輸入：
‘ OR 1=1 —

SQL 將被改寫為：
SELECT * FROM users WHERE username=” OR 1=1 –‘ AND password=’anything’

' 提前結束原查詢字串
OR 1=1 使條件永遠成立
-- 註解後續語句

由於 OR 1=1 永遠成立，結果資料庫會回傳所有使用者資料，系統可能直接以第一筆資料完成登入，成功繞過驗證。

在實際測試中，於登入欄位輸入上述指令即可觸發攻擊；若未部署防護，除可能造成資料外洩外，大量查詢亦可能導致系統負載上升。
而於部署 AWS WAF 並套用 SQL Injection 防護規則後，相同攻擊請求會在進入應用前被攔截，並於 WAF 後台顯示對應阻擋紀錄。

SQL Injection 防禦實作：從程式修補到 AWS WAF 部署

方法一：應用層防護

防禦 SQL Injection 最直接方式是修正應用程式邏輯。

例如使用參數化查詢：
sql = “SELECT * FROM users WHERE username = ? AND password = ?”
cursor.execute(sql, (username, password))

此方式可避免輸入被解析為 SQL 指令，從源頭降低注入風險。

然而，在實務環境中，僅依賴應用層防護仍存在限制：

舊系統修補成本高
攻擊手法持續演進
自動化掃描與攻擊頻繁

因此需搭配架構層防護形成完整策略。

方法二：架構層防護

在實務部署中，AWS WAF 無法直接關聯至 EC2 執行個體或彈性公網 IP (EIP)，需透過負載均衡器（如 ALB，Application Load Balancer）或 AWS CloudFront 前端作為中介層。
此設計可擴大防護範圍，並提升架構彈性與調整空間。
*本文已经提前架設一個簡單的ABL負載均衡器用於本次測試。