資料庫大門忘了鎖？WordPress SQL Injection 終極防禦指南，從菜鳥到老鳥都該懂的攻防戰！

哈囉，我是浪花科技的資深工程師 Eric。在鍵盤上打滾了這麼多年，看過太多網站從雲端摔落地獄的慘案。很多時候，不是因為什麼高深的駭客技術，而是敗在一個微小卻致命的漏洞 —— SQL Injection（SQL 注入攻擊）。這玩意兒就像網站的癌症，初期無聲無息，一旦爆發，輕則資料外洩、商譽掃地，重則整個網站直接被捧去「種」了。

今天，我不想只跟你說「用某某函式就好」，那太不負責任了。身為一個囉嗦的工程師，我想帶你從根本上理解 SQL Injection 的攻防邏輯，並建立一套 WordPress 的「縱深防禦」策略。這不只是一篇技術教學，更是一場保護你數位資產的關鍵戰役。

什麼是 SQL Injection？為什麼它像網站的『癌症』一樣致命？

我們先來拆解一下這個名詞。SQL (Structured Query Language) 是我們跟資料庫溝通的語言，就像你跟 Siri 說話一樣。我們透過 SQL 指令去新增、讀取、更新、刪除資料庫裡的資料。而「Injection」（注入）的意思，就是駭客想辦法在你正常的 SQL 指令中，偷偷「注入」了他們惡意的指令片段。

SQL 注入攻擊的原理：一個簡單卻致命的範例

想像一下，你有一個簡單的登入表單，後端程式碼可能是這樣處理的（這是一個錯誤的範例）：

// ！！！這是一個極度不安全的範例，請勿模仿！！！
$username = $_POST['user'];
$password = $_POST['pass'];

$sql = "SELECT * FROM users WHERE username = '" . $username . "' AND password = '" . $password . "'";
$result = $database->query($sql);

正常情況下，使用者輸入帳號密碼，SQL 指令會長得像這樣：SELECT * FROM users WHERE username = 'eric' AND password = 'mysecretpassword'。

但如果一個駭客在帳號欄位輸入 ' OR '1'='1' --，猜猜會發生什麼事？

組合起來的 SQL 指令會變成：

SELECT * FROM users WHERE username = '' OR '1'='1' -- ' AND password = '...'

在 SQL 語法裡，'1'='1' 永遠是成立的 (true)，而 -- 是註解符號，會讓後面的密碼驗證直接失效。所以這段指令的意思變成「從 users 資料表裡選出所有使用者，條件是…使用者名稱是空的，或者 1=1」。結果就是，駭客不用密碼就成功登入了！這還只是小菜一碟，更狠的可以直接注入 DROP TABLE users;，你的使用者資料就瞬間人間蒸發。

WordPress 世界中的 SQLi 風險

你可能會想：「WordPress 這麼大的平台，核心程式碼應該很安全吧？」沒錯，WordPress 核心團隊在資安方面下了非常大的功夫，核心本身爆發 SQLi 漏洞的機率極低。但問題出在哪？答案是：外掛（Plugins）與主題（Themes）。

根據 Wordfence 或 Patchstack 這類資安公司的報告，每個月都有數十甚至上百個外掛被揭露存在漏洞，其中 SQL Injection 始終是榜上常客。很多外掛開發者（甚至是付費外掛）沒有遵循 WordPress 的安全開發規範，直接拼接 SQL 字串，就等於為駭客大開方便之門。這也是為什麼我總是一再強調，安裝外掛前一定要三思，不是裝越多越好。

WordPress 防禦 SQL Injection 的第一道，也是最重要的防線：`$wpdb->prepare()`

好了，講了這麼多恐怖故事，該來點正經的了。如果你是個 WordPress 開發者，$wpdb->prepare() 這個函式你就算沒用過，也肯定聽過。很多人以為它只是個『格式化』工具，那就大錯特錯了。這傢伙根本就是你資料庫的保全大哥！

`prepare()` 的運作原理：不只是字串取代

$wpdb->prepare() 的核心精神是「參數化查詢」（Parameterized Queries）。它的運作方式是，先把 SQL 指令的「結構樣板」送到資料庫伺服器，告訴它：「嘿，我等一下要執行的指令長這樣，但有幾個地方的資料我先空下來。」接著，再把使用者輸入的「資料」傳過去。資料庫會很清楚地知道，後面傳來的東西純粹是「資料」，就算裡面包含 ' OR '1'='1'，也只會把它當成一個叫「’ OR ‘1’=’1’」的普通字串去搜尋，而不會當成指令來執行。這就從根本上杜絕了注入的可能性。

錯誤的示範 vs. 正確的寫法

讓我們來看看實際的程式碼，這會更有感覺。假設我們要根據文章 ID 查詢作者。

❌ 錯誤的寫法（極度危險）：

global $wpdb;
$post_id = $_GET['id']; // 直接從使用者輸入取得資料
$author = $wpdb->get_var("SELECT post_author FROM $wpdb->posts WHERE ID = $post_id");

如果駭客傳入的 `id` 是 1 OR 1=1，你的資料庫可能就會開始噴出不該給的資訊。

✅ 正確的寫法（安全可靠）：

global $wpdb;
$post_id = intval($_GET['id']); // 先做基本的型別驗證

// 使用 $wpdb->prepare()
$query = $wpdb->prepare(
    "SELECT post_author FROM $wpdb->posts WHERE ID = %d",
    $post_id
);

$author = $wpdb->get_var($query);

看到了嗎？我們用 %d 作為「佔位符」（placeholder），代表這裡應該是一個整數（integer）。然後在第二個參數把 $post_id 變數傳進去。prepare() 會幫我們安全地處理好一切。常用的佔位符有：

• %d: 整數 (integer)
• %f: 浮點數 (float)
• %s: 字串 (string)

工程師的小囉嗦： 記住一個黃金法則：任何、任何、任何（很重要所以說三次）來自使用者端（$_GET, $_POST, $_REQUEST, $_COOKIE）或任何你不完全信任的來源的變數，只要它會進入 SQL 查詢，就必須、必須、必須用 $wpdb->prepare() 包起來！ 沒有例外。

縱深防禦：超越 `$wpdb->prepare()` 的多層次安全策略

只靠 $wpdb->prepare() 就像只靠一個門鎖保護整棟豪宅，雖然很堅固，但有智慧的竊賊總會想辦法繞過它。真正的安全，來自於層層堆疊的防禦工事，也就是「縱深防禦」（Defense in Depth）。

第一層：輸入驗證與淨化 (Input Validation and Sanitization)

在資料進入資料庫查詢之前，就應該先把它「洗乾淨」。WordPress 提供了很多好用的函式：

• intval(), absint(): 如果你預期的是一個正整數，就用它們。直接把不是數字的東西變成 0。
• sanitize_text_field(): 最常用的函式之一，會移除不必要的標籤和空白，確保輸入是乾淨的單行文字。
• sanitize_email(): 清理並驗證 email 格式。
• esc_sql(): 這是個比較低階的函式，它只會對字串做跳脫處理。它的安全性遠不如 $wpdb->prepare()，只應該在無法使用 `prepare` 的極少數情境下作為最後手段。

第二層：最小權限原則 (Principle of Least Privilege)

這個原則適用於兩個層面：

1. 資料庫使用者權限： 你的 wp-config.php 裡設定的資料庫使用者，權限越小越好。它只需要對 WordPress 的資料庫有讀寫權限就夠了，絕對不要給它 SUPER, FILE 或甚至是對其他資料庫的操作權限。
2. WordPress 使用者角色： 在你的程式邏輯中，執行敏感操作前，務必用 current_user_can() 檢查當前使用者是否有足夠的權限。例如，刪除文章的功能，就應該檢查 current_user_can('delete_post', $post_id)。

第三層：Web 應用程式防火牆 (WAF)

WAF 就像是你網站門口的保全，它會在惡意請求到達你的 WordPress 之前就把它攔截下來。服務如 Cloudflare、Sucuri，或是 Wordfence 這類外掛都提供了 WAF 功能。它們會根據已知的攻擊模式（例如 URL 中包含 ' OR '1'='1'）來過濾流量，能有效擋掉大部分自動化的掃描攻擊。

第四層：保持更新與監控

這點雖然老生常談，卻是最多人忽略的。駭客最喜歡攻擊的就是那些萬年不更新的網站。定期更新 WordPress 核心、所有外掛與主題，就是修補已知的安全漏洞。同時，安裝一個好的安全監控外掛，它能在你的網站檔案被竄改或出現可疑行為時，第一時間通知你。

實戰演練：一個安全的自訂查詢流程

讓我們把以上所有觀念串起來，假設我們要寫一個功能，讓已登入的訂閱者 (subscriber) 可以查詢自己發布過的某個自訂文章類型 (custom post type) `my_cpt`。

function safe_custom_search_handler() {
    // 步驟 1: 檢查使用者權限，未登入或權限不足就直接中斷
    if ( ! is_user_logged_in() || ! current_user_can('read') ) {
        wp_die('您沒有權限執行此操作。');
    }

    // 步驟 2: 取得並淨化使用者輸入
    // 假設使用者透過 GET 參數傳入關鍵字
    $keyword = isset($_GET['search_keyword']) ? sanitize_text_field($_GET['search_keyword']) : '';

    if ( empty($keyword) ) {
        echo "請輸入查詢關鍵字。";
        return;
    }

    global $wpdb;
    $current_user_id = get_current_user_id();

    // 步驟 3: 使用 $wpdb->prepare() 建立安全查詢
    // 注意 LIKE 查詢的 % 符號要特別處理
    $wild = '%';
    $like_keyword = $wild . $wpdb->esc_like($keyword) . $wild;

    $query = $wpdb->prepare(
        "SELECT ID, post_title FROM {$wpdb->posts} " .
        "WHERE post_author = %d " .
        "AND post_type = 'my_cpt' " .
        "AND post_status = 'publish' " .
        "AND post_title LIKE %s",
        $current_user_id,
        $like_keyword
    );

    // 步驟 4: 執行查詢
    $results = $wpdb->get_results($query);

    // 步驟 5: 處理並安全地輸出結果 (防範 XSS)
    if ( $results ) {
        echo '
';
        foreach ( $results as $post ) {
            // 使用 esc_html() 來輸出，避免 XSS 攻擊
            printf(
                '
%s
',
                esc_url(get_permalink($post->ID)),
                esc_html($post->post_title)
            );
        }
        echo '
';
    } else {
        echo "找不到相關結果。";
    }
}

你看，一個安全的流程，從權限檢查、輸入淨化、參數化查詢到安全輸出，環環相扣，這才是專業的開發態度。

結論：安全不是選項，而是責任

寫程式碼就像蓋房子，地基歪了，上面蓋得再漂亮都沒用。資料庫安全就是那個地基。多花五分鐘用 $wpdb->prepare()，多想一步做權限檢查和輸入驗證，可以省下你未來五天（甚至五個禮拜）的救災時間。這投資，絕對划算。

希望這篇囉嗦的長文能讓你對 WordPress 的 SQL Injection 防護有更深層的理解。安全不是一次性的工作，而是一種持續的習慣與心態。保護好你的網站，就是保護好你的客戶與你自己的心血。

延伸閱讀

• 你的 Code 在哭泣！資深工程師帶你用 $wpdb->prepare() 徹底根治 WordPress SQL Injection 漏洞
• 你的表單安全嗎？揭開 WordPress Nonces 的神秘面紗，杜絕 CSRF 攻擊的終極防線！
• 網站半夜被黑？別怕！資深工程師的 WordPress 終極安全指南，從預防到災難復原全攻略

如果你對於網站的安全性有任何疑慮，或是需要更專業的程式碼審查與安全加固服務，浪花科技的團隊隨時準備好提供協助。別等到出事了才來找醫生！

立即聯繫浪花科技，為您的網站建立銅牆鐵壁！