$wpdb SQL 注入審查四規則
$wpdb SQL 注入審查四規則
概述
一套不需會發動攻擊、也能審查 WordPress 外掛 SQL 注入風險的人工自檢規則。專管「查詢端」——使用者可控輸入（網址參數、表單、API 參數）一路流到 $wpdb 的不安全用法。與管「寫入端」的 [[攻擊者視角安全稽核四問]] 互補，合起來才覆蓋外掛的資料庫攻擊面。核心心法：拿到 AI 生成的外掛，搜一下 $wpdb，每個出現處逐條跑一遍。
步驟
四條規則
- 有沒有用 prepare？ 看到 $wpdb 直接拼字串、後面沒接 prepare，最基本的漏洞，先標起來。
- 是不是只 prepare 一半？ 看 prepare 的 SQL 範本裡有沒有變數「直接黏在裡面」（而不是用 %s、%d 填空格）。只要有變數直接內嵌，那個變數就完全沒受保護——攻擊面原封不動。
- 填空格有沒有放錯位置？ 填空格（%s、%d）出現在 ORDER BY、GROUP BY、欄位名、表格名這類「填名稱」的地方擋不住，且常因排序失效被開發者改回拼字串。要改用白名單，或在新版用 %i 識別字。
- LIKE 有沒有配 esc_like、IN 清單有沒有整數化？ LIKE 的 % 與 _ 是萬用字元，prepare 不處理，要搭
$wpdb->esc_like()；IN 清單長度不固定、prepare 無現成語法，常被直接拼陣列，至少要先把每個元素強制轉整數，或依長度動態產生填空格。
審查心法
- 後三條都是「用了 prepare 卻沒用對」。能抓「用錯」比抓「沒用」更有價值，因為需要更深一層的眼力，也正是 AI 最容易騙過審查的地方。
- 不需會打通漏洞，只要能看出「使用者可控輸入 → $wpdb 不安全用法」這條資料流是否存在，就足以是重大發現。
適用場景
- 審查 AI（Vibe Coding）生成的 WordPress 外掛，尤其是有搜尋、篩選、排序、自訂列表、批次操作的外掛
- 接案者交付前的 SQL 安全自檢
- 任何使用自訂資料表、繞過 WordPress 內建 API 的查詢邏輯
限制
- 只管查詢端注入，寫入端入口需搭配 [[攻擊者視角安全稽核四問]]（驗本人、查資格、誤開放、寫入白名單）。
- 白名單在輸入空間無法窮舉時失效，需補型別驗證與安全輸出。
- 人工自檢不取代自動化掃描與滲透測試，也不涵蓋站台層防護（弱密碼、檔案竄改、XML-RPC）。
關聯概念
- [[SQL 注入防範]]
- [[攻擊者視角安全稽核四問]]
- [[縱深防禦]]
- [[攻擊者思維稽核]]