SQL 注入防範

概念

SQL 注入防範

定義

防止攻擊者透過使用者輸入，把惡意 SQL 指令「注入」進原本的查詢並被資料庫執行的一組做法。本質問題是「資料庫分不清楚哪些是指令、哪些是資料」——只要使用者輸入被當成 SQL 結構的一部分執行，就成立注入。核心解法是參數化查詢（prepared statement）：把 SQL 範本與資料分開傳遞，資料一律鎖在「填空格」位置，永遠不會被當成指令。在 WordPress 中，這個工具是 $wpdb->prepare。

關鍵數據點（附來源）

  • WordPress 沒有官方 ORM，外掛實務幾乎是直接用 $wpdb 寫原生 SQL，所以審查外掛安全很大一部分就是看 $wpdb 的用法。一般讀寫用內建 API（WP_Query、get_option）已含安全處理；風險集中在「需要自訂資料表」的複雜外掛。（wordpress-wpdb-sql-injection-review）
  • 真正高頻的漏洞不是「沒用 prepare」，而是「用了 prepare 卻用錯」的四種破口：①只 prepare 一半（變數在 prepare 外就拼進字串）②把欄位名/排序丟進填空格（擋不住，且開發者常因排序失效而改回拼字串）③LIKE 忘了 esc_like（% 與 _ 是萬用字元，prepare 不處理）④IN 清單直接拼陣列。（wordpress-wpdb-sql-injection-review）
  • Patchstack 年度報告：SQL Injection 至今仍是 WordPress 外掛排名前五的漏洞類型，每月新增十幾二十個。AI 生成程式碼特別容易踩中，因為它知道「要用 prepare」的規則，卻不懂死角在哪。（wordpress-wpdb-sql-injection-review）
  • prepare 救不了「填名稱」的位置（欄位名、表格名、ORDER BY），這類要用白名單（列舉合法選項，不在名單就用預設值）。WordPress 6.2 後新增 %i 識別字填空格，但採用率低、舊版會壞，白名單仍是最穩解。（wordpress-wpdb-sql-injection-review）

前提與局限性

  • prepare 只是 [[縱深防禦]] 的第一道防線，管的是「查詢端」的注入；外掛還有「寫入端」入口（後台 AJAX、表單、Webhook）要靠 [[攻擊者視角安全稽核四問]] 的權限與白名單。兩者互補，缺一不可。
  • 白名單假設「合法輸入可被列舉」。輸入空間爆炸（富文本、檔案上傳）時白名單失效，需改型別驗證 + 安全輸出。
  • 4 條審查規則是人工自檢，目的是快速抓最常見、AI 最易寫錯的破口，不取代自動化掃描與滲透測試。
  • 此風險的「重心在 $wpdb」是 WordPress 特性（無官方 ORM）；換到有 ORM 的技術棧，預設注入面較小，但 raw query 仍是同樣破口。

衝突標記

（無）

關聯概念

  • [[縱深防禦]]
  • [[攻擊者視角安全稽核四問]]
  • [[攻擊者思維稽核]]
  • [[ai-是放大器]]
  • [[wordpress-外掛開發實踐]]