如何選擇 SQL 注入掃描工具

例如，假設搜尋表單中輸入的值，會直接被拼接成 SQL 敘述的一部分。動態檢測會實際傳送請求，從回應差異等線索尋找問題。程式碼分析則會追蹤值從哪裡進入，以及被傳入什麼樣的查詢。

動態檢測若無法存取頁面或 API，就無法進行檢查。程式碼分析也可能因支援的語言、框架，以及分析對象的設定而有所遺漏。即使其中一種方式的檢出結果為零，也不能據此判斷另一種方式已無必要。

ZAP：想檢查整個 Web 應用程式時，可考慮的開放原始碼工具。它提供 SQL 注入的主動掃描規則，也能一併檢查其他 Web 漏洞。不過，ZAP Baseline 預設使用被動掃描，因此不能只因執行了它，就認為已完成 SQL 注入的主動檢測。

sqlmap：懷疑某個特定輸入點有問題，想針對 SQL 注入進行重點驗證時，可使用的開放原始碼工具。它除了偵測功能，也具備自動化漏洞利用功能，因此使用前應先確定授權範圍，並在能控制影響的環境中使用。

Burp Suite Professional：適合想一邊檢視 HTTP 請求，一邊結合掃描器與手動驗證的負責人員。自動掃描器包含在付費的 Professional 等版本中，免費的 Community Edition 並未包含此功能。

Wapiti：透過命令列，以黑箱方式檢查 Web 應用程式的開放原始碼工具。官方文件介紹了利用錯誤、布林值及時間差進行的 SQL 注入檢測，以及使用 OpenAPI 檔案進行的 API 掃描。對於包含 SPA 或複雜驗證機制的對象，請個別驗證工具是否能存取必要的路徑。

這些工具都會向執行中的應用程式傳送請求。除了頁面，也應涵蓋通過驗證後的 API、管理介面及各使用者的權限，並將實際能存取到的範圍與結果一併記錄。使用原始碼進行的靜態分析，則可作為另一種選項搭配使用。

在同一個預備環境中，準備已知有問題的輸入，以及已安全參數化的輸入，進行比較。除了確認能否找出前者，也要確認是否會將後者誤判為問題。另請確認檢測是否因驗證失效而中途停止，以及是否已遍歷包含 JSON API 在內的必要入口。

掃描可能影響測試資料或可用性。請取得對象擁有者的明確授權，就目標範圍、執行時間、負載及排除的操作達成共識，並盡可能在與正式環境分離的環境中測試。

NVD 記錄的 MOVEit Transfer 漏洞 CVE-2023-34362 指出，SQL 注入可能讓未經驗證的攻擊者存取資料庫，並記載了 2023 年 5 至 6 月間的漏洞利用情況。開發時，不僅要檢查登入後的處理流程，也必須確認公開路徑。以下是使用 TypeScript 與 node-postgres 的虛構教學範例，並非 MOVEit 的實作，也不是重現該 CVE 的程式碼。請僅針對已獲授權的對象進行檢測。

修正的基本原則是，不將外部傳入的值串接到 SQL 字串中，而是以參數方式傳入。不過，排序方式、資料表名稱等 SQL 結構本身，有時無法只靠值的繫結來處理。這種情況下，應從應用程式端預先準備的固定選項中選擇。

下一個範例會繫結搜尋值，並從兩個固定查詢中選擇排序方式。此外，也要將資料庫使用者的權限限制在必要的最小範圍，並另行確認使用者是否有權查看該資料。修正後，應重新驗證原先指出的問題已解決，而且一般搜尋功能未受破壞。

import type { Pool } from "pg";

export async function findProducts(
  db: Pool, name: string, sort: string,
) {
  const queries = {
    newest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at DESC, id DESC LIMIT 50",
    oldest: "SELECT id, name FROM products WHERE name = $1 ORDER BY created_at ASC, id ASC LIMIT 50",
  } as const;
  if (sort !== "newest" && sort !== "oldest") {
    throw new Error("Invalid sort");
  }
  return db.query(queries[sort], [name]);
}