全方位防禦 SQL Server 注入攻擊：從資料庫到應用層的實務指南

SQL 注入仍是面向網際網路之 SQL Server 資料庫最常見的攻擊手法。近年自動化注入攻擊激增，不僅竊取資料、破壞資料表，更植入惡意 JavaScript 感染客戶端。即使網路防火牆再嚴密，只要應用程式使用動態 SQL 且未驗證輸入，風險依然存在。

攻擊原理解析

攻擊者在輸入欄位植入單引號、分號或轉義字元，竄改原本 SQL 命令。例如：

exec sel_CustomerData @CustomerId=47663; truncate TABLE Customer

資料庫將先執行預存程序，再執行 TRUNCATE TABLE 刪除資料。若有外鍵約束，錯誤訊息甚至會洩露資料表結構，助長進一步攻擊。

防禦三大支柱

1. 資料庫層：最小權限與封裝存取

• 應用程式帳號僅授予 執行預存程序 權限，拒絕直接存取資料表。
• 所有預存程序禁止動態 SQL 拼接，改用參數化查詢。
• 停用不必要的擴充預存程序（xp_cmdshell、sp_OA* 等），降低攻擊面。

2. 應用層：嚴格輸入驗證與參數化

• 所有外部輸入（表單、QueryString、Cookie、HTTP Header）皆視為不受信任，實施 白名單驗證（型別、長度、格式、允許字元集）。
• 資料存取層全面採用參數化命令（SqlCommand.Parameters、Entity Framework、Dapper 等 ORM 內建參數化），嚴禁字串拼接 SQL。
• 錯誤訊息不回傳給前端，改記錄至伺服器端日誌，避免洩露結構描述資訊。

3. 維運層：稽核與監控

• 啟用 SQL Server 稽核 或 擴充事件 記錄失敗登入、權限變更、動態 SQL 執行等可疑行為。
• 定期掃描資料庫異常物件（未授權的預存程序、觸發器、連結伺服器）。
• 備份檔案加密儲存，離線保存，防止備份外洩被還原竊取。

常見迷思澄清

• 「改用 Oracle/PostgreSQL 就安全」 → 所有關聯式資料庫皆受注入威脅，關鍵在應用程式寫法。
• 「WAF 就能攔截所有攻擊」 → WAF 為第二道防線，無法替代程式碼層面的參數化防禦。
• 「預存程序天生免疫」 → 若預存程序內部仍用 EXEC(@sql) 拼接字串，同樣脆弱。

結語

防禦 SQL 注入非單一工具可達成，需「資料庫最小權限 + 應用層參數化 + 持續稽核」三位一體。開發階段即納入安全編碼規範，配合程式碼審查與自動化掃描工具，才能從根本降低風險。