SQL Injection（SQL 注入）是針對資料庫層的攻擊，攻擊者透過在輸入中注入惡意 SQL 片段，改變伺服器執行的查詢邏輯，進而讀取、修改或刪除資料庫內容，甚至取得系統控制權。這類漏洞在實務中仍頻繁發生，影響範圍從資料外洩到整個系統被破壞，風險極高。

⸻

一、攻擊原理（精簡說明）

應用程式把使用者輸入直接拼接進 SQL 查詢字串，導致攻擊者能構造額外的 SQL，改變原本查詢的語意。例如把驗證邏輯、where 條件或資料操作替換為攻擊者想要的指令。
二、簡單示範（具說明性的範例）

危險範例（不要在生產環境使用） — 以 PHP + MySQL 為例：

// 假設從 POST 取得使用者輸入的帳號
$username = $_POST['username'];
// 直接拼接 SQL（易受注入）
$sql = "SELECT * FROM users WHERE username = '$username' AND active = 1";
$result = mysqli_query($conn, $sql);
若攻擊者在 username 輸入：
' OR '1'='1
則組成的 SQL 可能成為：
SELECT * FROM users WHERE username = '' OR '1'='1' AND active = 1;

三、常見利用情境與後果
• 認證繞過：登入表單被繞過，攻擊者可當作合法使用者。
• 資料外洩：讀取敏感欄位（身分證、電子郵件、密碼雜湊）。
• 資料破壞：刪除或修改資料（DELETE、UPDATE）。
• 命令執行/資料庫側通道：在特定設定下可能進一步執行系統指令或上傳惡意程式。

⸻

四、防禦重點（落地可執行）
1. 使用參數化查詢（Prepared Statements）／綁定參數（首選）
• 所有 SQL 請求皆使用參數化語法，避免把使用者輸入直接拼接進字串。
• 範例（PHP mysqli prepared）：

$stmt = $conn->prepare("SELECT * FROM users WHERE username = ? AND active = 1");
$stmt->bind_param("s", $username);
$stmt->execute();

2. 輸入驗證與白名單（Whitelist）
   • 對於期望格式（Email、數字 ID、日期等）採白名單驗證，拒絕不符格式的輸入。
   • 對於枚舉型輸入（sort、filter）用映射表替代直接接受字串。
   3. 最小權限原則（DB account）
   • 應用程式使用的資料庫帳號只給予必要權限（例如只可 SELECT/INSERT/UPDATE，不給 DROP、ALTER）。
   • 分離管理帳號與應用帳號。
   4. 避免顯示詳細錯誤訊息（Error Handling）
   • 不將資料庫錯誤直接回傳給使用者，避免洩露結構或欄位資訊；將錯誤記錄在安全日誌中供鑑識使用。
   5. 使用 ORM 或安全的資料存取層
   • 合理使用成熟的 ORM（如 Hibernate、ActiveRecord、Entity Framework 等）能減少錯誤拼接 SQL 的機會，但仍需正確使用參數化 API。
   6. 資料庫層防護（WAF / SQL 防護規則）
   • 部署 Web Application Firewall（WAF）或資料庫行為偵測，作為額外防線，可攔截已知攻擊樣式。
   7. 定期代碼審查與掃描（SAST/DAST）
   • 使用靜態程式碼分析（SAST）與動態掃描（DAST）工具檢測注入漏洞，並進行手動程式碼審查關鍵區段。
   8. 日誌與異常監控
   • 設定異常查詢行為的告警（例如短時間內重複出現結構性異常查詢），保存查詢日誌以利鑑識。

⸻

五、實務建議（開發與營運）
• 在開發階段就把安全當作需求：把參數化、輸入驗證納入範本（template）與 code review checklist。
• 測試時納入注入測試案例：CI/CD pipeline 可加上自動化的安全掃描。
• 定期演練 Incident Response：若發現 SQL Injection 被利用，要能快速封鎖、回溯並修補。
• 教育團隊成員：讓前端、後端與 DBA 都理解注入的成因與防護方式，避免跨層誤解。

⸻

結語

SQL Injection 是可預防、卻代價高昂的漏洞。關鍵在於「永遠不要把未經處理的使用者輸入當成 SQL 字串的一部分」。採用參數化查詢、白名單驗證與最小權限等防護措施，並結合掃描與監控，才能從源頭與運維兩端有效降低風險。