你的 Code 在哭泣！資深工程師帶你用 $wpdb->prepare() 徹底根治 WordPress SQL Injection 漏洞

嗨，我是浪花科技的 Eric。身為一個整天在程式碼跟伺服器之間打滾的工程師，我看過太多令人頭皮發麻的 WordPress 後台。但最讓我半夜驚醒的，不是客戶奇怪的需求，也不是 UI 設計師天馬行空的創意，而是在 custom theme 或 plugin 裡看到那一行赤裸裸、毫無防備的 SQL 查詢。

「不就是個簡單的資料查詢嗎？幹嘛搞那麼複雜？」我彷彿能聽到剛入門的開發者在內心吶喊。嘿，老兄，就是這個「不過是」，讓無數網站的資料庫成了駭客的後花園，隨時都能進來散步、帶走點紀念品。今天，我們不談那些虛無飄渺的理論，就來聊聊 WordPress 開發中最致命、也最容易被忽略的敵人 —— SQL Injection (SQL 注入攻擊)，以及如何用 WordPress 內建的神兵利器 $wpdb->prepare() 把它徹底根絕。

SQL Injection：當你的資料庫「聽懂」了不該聽的話

在我們動手寫 Code 之前，先花個兩分鐘，用工程師的白話文搞懂 SQL Injection 到底是什麼鬼。想像一下，你的 SQL 查詢語法就像一句你對資料庫下的命令：「嘿，資料庫，幫我從 `users` 這張桌子裡，找出 `ID` 是 5 的使用者資料。」

一個寫法有漏洞的程式碼，就像一個耳根子軟的傳令兵。你告訴他：

"SELECT * FROM users WHERE ID = " . $_GET['user_id'];

正常情況下，使用者傳來 `user_id=5`，傳令兵就喊出：「找出 ID 是 5 的使用者！」一切安好。

但如果來了個壞蛋，他傳來的 `user_id` 是 5 OR 1=1 呢？那個天兵傳令兵就會對資料庫大喊：「找出 ID 是 5 或者 1=1 的使用者！」因為 `1=1` 永遠是對的，所以結果是什麼？沒錯，資料庫會把「所有」使用者的資料都吐回來。你的使用者名單、Email、甚至密碼雜湊值，就這樣被人看光光了。這還只是最基本的，高明的駭客甚至可以透過注入攻擊來刪除資料、修改權限，甚至讀寫伺服器上的檔案。

這就是 SQL Injection 的核心：利用程式碼的漏洞，將惡意的 SQL 指令片段「注入」到原始的查詢語句中，欺騙資料庫去執行開發者意想不到的操作。 每次我看到沒做防護的 SQL 查詢，都彷彿聽到那段程式碼在無聲地哭泣，哀嚎著它即將被濫用的命運。

WordPress 的金鐘罩：$wpdb->prepare() 終極指南

好了，恐嚇時間結束。WordPress 核心團隊當然知道這個問題的嚴重性，所以他們提供了一個非常強大的工具來解決這個問題：$wpdb->prepare() 方法。這不是什麼新潮的技術，它其實就是「預備語句 (Prepared Statements)」的 WordPress 版本，也是防範 SQL Injection 的黃金標準。

它的原理很簡單：將 SQL 查詢的「指令結構」和要傳入的「資料」徹底分開處理。 無論使用者傳入的資料多麼陰險，都會被當成純粹的字串或數字，而不是可以被執行的指令。就像你給傳令兵一張寫好命令的「模板」，然後把使用者的輸入當成「填空題」的答案塞進去，他永遠只能照著模板唸，無法更改命令本身。

基本功：字串 (%s) 與數字 (%d) 的正確用法

prepare() 的語法非常直觀：第一個參數是你的 SQL 查詢模板，後面接著一個或多個要代入模板的變數。模板中使用「預留位置 (placeholder)」來標示變數將被插入的地方。

• %s：用於字串 (string)
• %d：用於整數 (decimal/integer)
• %f：用於浮點數 (float)

讓我們來看看血淋淋的「錯誤示範」與刀槍不入的「正確示範」。

錯誤的寫法 (危險！)：

這種寫法等於是把家門鑰匙直接掛在門上。

<?php
global $wpdb;
$user_id = $_POST['user_id']; // 直接從使用者輸入取得
$user_status = 'active';

// 直接將變數拼接到 SQL 字串中，駭客的提款機！
$user_email = $wpdb->get_var(
    "SELECT user_email FROM {$wpdb->users} WHERE ID = {$user_id} AND user_status = '{$user_status}'"
);
?>

正確的寫法 (安全！)：

這才是專業開發者該有的樣子。所有外部變數都透過 `prepare` 處理。

<?php
global $wpdb;
$user_id = (int) $_POST['user_id']; // 順手做個型別轉換是好習慣
$user_status = 'active';

// 使用 prepare 將查詢與資料分離
$user_email = $wpdb->get_var(
    $wpdb->prepare(
        "SELECT user_email FROM {$wpdb->users} WHERE ID = %d AND user_status = %s",
        $user_id,
        $user_status
    )
);
?>

看到了嗎？在正確的寫法中，$user_id 和 $user_status 被當成參數傳遞給 prepare()。WordPress 會確保傳入 %d 的值絕對是數字，傳入 %s 的值會被妥善地跳脫 (escape)，任何惡意的 SQL 特殊字元（例如單引號）都會被處理成無害的普通字元。這就從根本上杜絕了注入的可能性。

進階挑戰：那些讓你抓狂的 LIKE 與 IN 子句

如果你以為學會 %s 和 %d 就天下無敵了，那你就太天真了。實務上，有兩個常見的 SQL 子句是 `prepare()` 的罩門，也是很多開發者踩坑的地方。

1. LIKE 模糊搜尋的正確姿勢

很多人在處理搜尋功能時，會直覺地這樣寫：

$wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE post_title LIKE '%s'", "%$search_term%" ); // 錯誤！

看起來好像沒問題，但這通常不會如你預期地運作，而且在某些情況下仍然有風險。正確且安全的方式是，先用 $wpdb->esc_like() 來跳脫搜尋詞本身，然後再手動把萬用字元 % 加上去。

<?php
global $wpdb;
$search_term = $_GET['keyword'];

// 1. 使用 $wpdb->esc_like() 來跳脫搜尋關鍵字中的特殊字元 (_, %)
$like_pattern = '%' . $wpdb->esc_like($search_term) . '%';

// 2. 將完整的模式作為一個字串傳入 prepare
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT ID, post_title FROM {$wpdb->posts} WHERE post_title LIKE %s",
        $like_pattern
    )
);
?>

記住這個流程：先 `esc_like`，再加 `%%`，最後才 `prepare`。這有點囉嗦，但為了安全，這點囉嗦是絕對值得的。

2. 處理 IN (…) 條件的動態寫法

另一個大魔王是 `IN` 子句。你不能直接把一個 PHP 陣列丟給 prepare()，它看不懂。

$wpdb->prepare( "... WHERE ID IN (%s)", implode(',', $id_array) ); // 絕對錯誤！

這樣做等於又回到了手動拼接字串的老路，完全繞過了 `prepare` 的保護。正確的作法是，根據陣列的元素數量，動態產生對應數量的預留位置。

<?php
global $wpdb;
$post_ids = [10, 25, 33];

// 確保陣列中的每個值都是整數，這是第一道防線
$post_ids = array_map('intval', $post_ids);

// 如果陣列是空的，就沒必要查詢了
if (empty($post_ids)) {
    return [];
}

// 根據陣列數量，產生對應數量的 %d
$placeholders = implode(', ', array_fill(0, count($post_ids), '%d'));

// 準備查詢語句
$query = "SELECT * FROM {$wpdb->posts} WHERE ID IN ({$placeholders})";

// 將查詢模板和整個陣列傳給 prepare
$results = $wpdb->get_results(
    $wpdb->prepare($query, $post_ids)
);
?>

這段程式碼看起來複雜了點，但它做的事情很標準：

1. 清理輸入陣列，確保都是數字。
2. 動態建立一個像 `(%d, %d, %d)` 這樣的字串。
3. 將最終的查詢模板和整個 ID 陣列一起傳遞給 `prepare()`。`$wpdb` 會聰明地將陣列中的每個元素依序對應到每個 `%d`。

防禦是多層次的：不只依賴 prepare()

雖然 $wpdb->prepare() 是我們對抗 SQL Injection 的主要武器，但一個好的防禦策略永遠是縱深的、多層次的。

• 優先使用 WordPress Core API： 在自己動手寫 SQL 之前，先問問自己：「這件事 `WP_Query`, `get_posts()`, `get_users()`, `get_term_by()` 這些函式能做到嗎？」WordPress 內建的這些高階查詢函式都已經幫你處理好安全性了。只有在功能極度複雜，非得要自訂 SQL 才能解決時，才輪到 `$wpdb` 上場。
• 資料驗證與清理 (Validation & Sanitization)： 在把資料送進 `prepare()` 之前，先做基本的驗證和清理。例如，如果你期待一個數字，就用 `intval()` 轉一下；如果你期待一個 Email，就用 `is_email()` 檢查一下。這就像在進入無塵室前先沖個澡，總是好的。
• 最小權限原則： 確保你的 WordPress 資料庫使用者權限是最小化的。它真的需要 `DROP` 或 `FILE` 權限嗎？大概率是不需要。萬一真的被駭客突破了，最小權限原則可以大幅限制他能造成的破壞。

寫出安全的程式碼，不只是為了防止網站被黑，更是身為一個專業開發者的基本素養。每次當你寫下一行直接拼接變數的 SQL 查詢時，請想像一下我這個老工程師在你背後，用一種「你確定要這樣做？」的眼神關愛著你。把 $wpdb->prepare() 養成肌肉記憶，你的程式碼會感謝你，未來的你也會感謝你。

相關文章推薦

• 你的 WordPress 網站是駭客的提款機？SQL Injection 終極防禦聖經，滴水不漏守護你的資料庫！
• 你的表單安全嗎？揭開 WordPress Nonces 的神秘面紗，杜絕 CSRF 攻擊的終極防線！
• 解鎖 WordPress 數據庫的鑰匙：WP_Query 終極指南，從入門到效能優化一篇搞定！

程式碼的安全是一條永無止境的修行之路。如果你在 WordPress 開發上遇到了更棘手的安全問題，或是需要為你的企業網站進行一次全面的安全健檢，浪花科技的團隊隨時準備好提供專業的協助。別等到出事了才來亡羊補牢。

👉 立即聯繫浪花科技，打造固若金湯的 WordPress 網站！