造成的原因

當今天一個使用 SQL的網站應用把使用者提供的資料直接放進SQL裡查詢，但並沒有做好該語法的檢查的話，就可能產生SQL Injection。

類型

三種類型

• In-Band:相同的通訊方式來發動漏洞利用並接收結果。
  • Error‑Based:用於取得資料庫結構資訊，因為資料庫產生的錯誤訊息會直接印到瀏覽器畫面上。這常能用來列舉整個資料庫。
  • Union‑Based:利用 SQL 的 UNION 運算子搭配 SELECT ，將額外的查詢結果回傳到頁面。這是透過 SQL 注入擷取大量資料最常見的方法。
• Blind:幾乎看不到任何回饋來確認所注入的查詢是否成功執行。這通常是因為錯誤訊息已被關閉或隱藏，但注入本身仍然有效。或許令人驚訝的是，只要有一點點回饋（例如真假判斷），就能逐步列舉整個資料庫。
  • Time-Based:看不到任何明確指示說查詢正確或錯誤。取代的是判斷查詢是否正確所需的時間長短。因此攻擊者可藉由觀察回應時間來判斷注入是否成功。
  • Boolean‑Based:回應只有兩種可能的結果(如true/false)，後續再利用這兩種回應來將整個資料庫挖掘出來
• Out-Band
  • 特徵是使用兩個不同的通訊通道：一個用來發動攻擊，另一個用來收集結果，較為少見。

可能的影響

1. 資料外洩

   攻擊者能讀出敏感資料（用戶資料、密碼雜湊、信用卡）。

2. 身分冒用

   透過操控查詢條件可跳過登入檢查或直接取得管理員使用者的認證資訊。

3. 資料篡改

   編輯、刪除或新增資料（改金額、修改權限、偽造交易紀錄等）。

4. 資料刪除 / 損毀

   永久刪除或破壞資料，造成營運或法規問題。

5. 遠端程式碼執行（在特定情況下）

   若 DB 支援執行外部程式或 shell，可能導致 RCE。

防禦方式

• 使用參數化查詢:不要把使用者輸入直接拼接到 SQL 字串中。
• 最小權限原則:應用程式使用的 DB 帳號只給予需要的權限，不使用高權限帳號連線。
• 預防多語句執行:關閉或過濾掉 ; 類可導致執行多語句的功能。
• 嚴格型別與輸入驗證:輸入做 allowlist驗證，如整數 ID 要用整數驗證、電子郵件格式驗證等。