WordPress 外掛 SQL Injection 防範 — 編譯摘要
濃縮
- WordPress 沒有官方 ORM，所以外掛安全的重心落在 $wpdb 的原生 SQL 用法：一般讀寫用內建 API（WP_Query、get_option、add_user_meta）就安全；一旦資料結構複雜到要自訂資料表，內建 API 認不得，只能用 $wpdb 直接下 SQL，安全就得自己顧。
- 證據：只要外掛要做搜尋、篩選、排序、自訂列表、批次操作，幾乎都會碰到 $wpdb；審查外掛安不安全，很大一部分就是看它怎麼用 $wpdb。
- 真正的風險不是「沒用 prepare」，而是「用了 prepare 卻用錯」：完全沒用 prepare 一眼就抓得到；危險的是四種「用了卻留破口」——只 prepare 一半（變數在 prepare 外就拼進字串）、把欄位名/排序丟進填空格（擋不住且常被改回拼字串）、LIKE 忘了 esc_like、IN 清單直接拼陣列。
- 證據：Patchstack 年度報告指出 SQL Injection 至今仍是 WordPress 外掛排名前五的漏洞類型，每月新增十幾二十個，多數不是沒用 prepare。AI 生成程式碼特別容易踩中，因為它知道「要用 prepare」的規則，卻不懂死角在哪。
- 審查可濃縮成 4 條可重複規則，不需會發動攻擊：只要能追「使用者可控輸入（網址、表單、API 參數）→ $wpdb 的不安全用法」這條資料流即可。這 4 條管「查詢端」，與既有「攻擊者四問」管「寫入端」互補。
- 證據：搜一下 $wpdb，每個出現處逐條跑（有沒有 prepare／是否只 prepare 一半／填空格放錯位置／LIKE+IN）。能抓「用錯」比抓「沒用」更有價值。
質疑
結論 1：WordPress 沒 ORM，重心在 $wpdb
- 前提假設：外掛開發實務上直接寫原生 SQL。
- 換技術棧：此論點是 WordPress 特有的風險來源。換到有官方 ORM 的框架（Laravel 的 Eloquent、Django ORM），開發者預設不手寫 SQL，這類注入面大幅縮小——但 ORM 的 raw query 仍是同樣破口。
- 邊界：純用內建 API 的外掛此風險低；風險集中在「需要自訂資料表」的複雜外掛。
結論 2：用了 prepare 卻用錯
- 前提假設：prepare 的死角在「填名稱」位置（欄位名、表格名、排序）與 LIKE/IN 等特殊語法。
- 可靠性：Patchstack 年度報告是 WordPress 漏洞資料的可靠來源，但「前五」「每月十幾二十個」屬趨勢級數字，非精確統計。
- 演化：WordPress 6.2 後新增 %i 識別字填空格可處理欄位/表格名，但採用率低、舊版用了會壞，所以白名單仍是最穩解。
- 邊界：白名單假設「合法輸入可被列舉」（排序欄位就那幾個，很適合）；輸入空間爆炸（富文本、檔案上傳）時白名單失效，得改型別驗證 + 安全輸出（沿用 [[縱深防禦]] 既有邊界）。
結論 3：4 條規則人工自檢
- 前提假設：審查者能讀懂資料流向。
- 反例 / 限制：人工自檢不取代自動化掃描與滲透測試（作者明確聲明）。當 4 條規則寫進 AI 的固定流程（Skill/checklist），AI 產出的安全性可逼近資深手寫水準——問題在流程設計，呼應 [[ai-是放大器]]。
對標
- 馮紐曼架構的 code/data 同源問題：SQL 注入的本質「資料庫分不清指令與資料」，與 shell injection、模板注入、甚至 LLM 的 prompt injection 是同一個元問題——在信任邊界內把不可信資料當成可控指令執行。參數化查詢（把資料鎖進填空格）正是「強制分離指令與資料」的通用解。
- 形式合規 ≠ 實質防護：「用了 prepare 卻用錯」對應安全領域的「虛假安全感」——戴了安全帽沒扣帶、洗手了沒洗對、做了 code review 卻只看功能。管理學的「合規 vs 實質」、醫療的手術部位查核表都在處理同一類「以為做了就有效」的失誤。能抓「用錯」需要比抓「沒用」更深一層的眼力。
- 點餐心智模型：菜單選項=指令、備註欄=資料，是參數化查詢最好的教學比喻，可遷移到任何要向非技術受眾解釋「指令/資料分離」的場景。
- 與既有概念關聯：prepare 是 [[縱深防禦]] 的第一道防線（後面接權限、白名單、未登入入口）；本文的查詢端 4 規則與 [[攻擊者視角安全稽核四問]] 的寫入端口訣互補，合起來才覆蓋外掛的資料庫攻擊面；承接 [[攻擊者思維稽核]] 的「追資料流」思路。
- 無衝突：與既有安全條目方向一致，補上知識庫缺的「查詢端 $wpdb 注入」拼圖（既有條目都聚焦寫入端的 CSRF/權限/白名單）。
![]()