你的 WordPress 網站是駭客的提款機？SQL Injection 終極防禦聖經，滴水不漏守護你的資料庫！

哈囉，我是浪花科技的資深工程師 Eric。今天不聊什麼酷炫的新功能或效能調校，我們要來談一個老掉牙但卻極度致命的問題，一個能讓你辛苦經營的網站一夕之間化為烏有的資安夢魘：SQL Injection (SQL 注入攻擊)。

你可能會想：「都什麼年代了，還在談 SQL Injection？」嘿，千萬別小看它。就像感冒一樣，雖然古老，但每年還是有大批人中鏢。在 WordPress 的世界裡，只要一個外掛、一段客製化程式碼的小疏忽，就可能讓駭客長驅直入，把你的資料庫當成自家的提款機，來去自如。這篇文章，我會用工程師的視角，帶你從原理、預防到實戰，徹底搞懂如何為你的 WordPress 網站建構一道滴水不漏的 SQL Injection 防火牆。

SQL Injection 到底是什麼鬼？用白話文說給你聽

我們先別急著看程式碼，那樣太勸退了。想像一下，你去圖書館的電腦查詢系統找書。系統有個欄位讓你輸入「書名」，然後它會去資料庫裡找書。

• 正常使用者：在欄位輸入「哈利波特」。系統執行的資料庫指令大概像這樣：SELECT * FROM books WHERE title = '哈利波特';
• 搞事的駭客：在欄位輸入了' OR '1'='1' --。這下好玩了，系統組合出來的指令變成：SELECT * FROM books WHERE title = '' OR '1'='1' -- ';

你看懂了嗎？因為 '1'='1' 永遠是成立的 (true)，這個指令就會繞過書名檢查，直接把圖書館裡「所有」的書都列出來！後面的 -- 則是註解符號，讓後面原本的語法失效，避免出錯。這只是一個最簡單的例子，駭客可以用更複雜的指令來竊取資料 (users 表單)、刪除資料 (DROP TABLE)，甚至取得整個伺服器的控制權。

簡單來說，SQL Injection 就是利用程式沒有對使用者輸入的內容做嚴格過濾的漏洞，將惡意的 SQL 指令「注入」到原本的查詢語句中，欺騙資料庫去執行非預期的動作。這就像你叫外送，結果外送員除了送餐，還順便把你家鑰匙給複製了一把，後果不堪設想。

WordPress 也會中招？揭開三大資安破口

很多人有個迷思：「我用的是 WordPress 這麼大的平台，核心應該很安全吧？」沒錯，WordPress 核心團隊在資安上下了很大功夫，核心本身是相對安全的。但問題往往不出在主堡，而是出在周邊的防禦工事，也就是整個 WordPress 生態系。

• 破口一：萬年不更新的外掛與佈景主題

  這是最常見、也最無腦的送頭方式。許多外掛或主題被發現有 SQL Injection 漏洞後，開發者會很快釋出更新檔。但如果你疏於更新，那你的網站就等於是掛著一個「歡迎駭客光臨」的牌子。別囉嗦，看到更新通知就快點按下去！

• 破口二：來路不明的「免費」資源

  在網路上找的所謂「開心版」、「專業版」的付費外掛或主題，99% 都被加料過，藏有後門或惡意程式碼。貪小便宜的下場，往往是付出更慘痛的代價。記住，天下沒有白吃的午餐，尤其在軟體世界。

• 破口三：工程師自己寫的「客製化」漏洞 (這最致命)

  這是我最想強調的一點。很多時候，專案需要客製化功能，我們會自己寫一些與資料庫互動的程式碼。如果沒有遵循最佳實踐，這就成了最大的漏洞來源。就算是資深工程師，在趕專案時也可能一時手滑，寫出有漏洞的查詢，這真的比什麼都可怕。

工程師的聖杯：用 `$wpdb->prepare()` 打造金鐘罩

好了，前面囉嗦了那麼多，終於要進入正題了。如果你是開發者，請把接下來這段話刻在你的腦子裡：在 WordPress 中，任何要代入變數的資料庫查詢，都必須、一定、絕對要使用 $wpdb->prepare()！

這不是建議，這是命令！每次在 code review 看到沒用 `prepare()` 的裸奔查詢，我的血壓都直接飆高。我們直接來看範例。

錯誤的示範（千萬別學！）

假設我們要根據使用者傳來的 ID 查詢一篇文章。

<?php
global $wpdb;
$post_id = $_GET['id']; // 直接從使用者輸入取得 ID
$results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}posts WHERE ID = $post_id" );
?>

上面這段程式碼，就是一個典型的 SQL Injection 漏洞。如果使用者在 URL 輸入的不是數字，而是一段惡意 SQL 語句，你的資料庫就準備被看光光了。

正確的寫法：使用 `$wpdb->prepare()`

$wpdb->prepare() 扮演著資料庫守門員的角色。它會先把你的 SQL 指令「範本」和要填入的「資料」分開處理。它會確保你傳入的資料就只是資料，絕對不會被當成指令來執行。這就是所謂的「預備陳述式 (Prepared Statements)」。

<?php
global $wpdb;
$post_id = $_GET['id']; // 從使用者輸入取得 ID

// 使用 prepare() 來處理查詢
$query = $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}posts WHERE ID = %d",
    $post_id
);

$results = $wpdb->get_results( $query );
?>

看到了嗎？我們把 SQL 查詢中的變數部分用一個「預留位置」%d 來代替。%d 代表這是一個數字 (decimal)，%s 代表字串 (string)，%f 代表浮點數 (float)。然後再把真正的變數 $post_id 當成第二個參數傳入。這樣一來，就算駭客傳入惡意字串，prepare() 也會把它當成一個普通的「字串」或「數字」來處理，而不是 SQL 指令的一部分，從根本上杜絕了注入的可能。

不只靠程式碼！網站管理員的防禦三部曲

就算你不是工程師，也別覺得事不關己。網站安全是每個人的責任。身為網站管理員，你可以做以下幾件事來大幅降低風險：

• 第一部：更新、更新、再更新

  很重要所以講三次。WordPress 核心、外掛、佈景主題，只要有更新就馬上處理。現在很多主機商也提供自動更新功能，請務必開啟它。

• 第二部：使用者權限，最小化原則

  不要貪圖方便，給所有人都「管理員」權限。一個小編只需要「作者」或「編輯」權限就夠了，他不需要安裝外掛或修改網站設定。遵循「最小權限原則 (Principle of Least Privilege)」，可以有效限制萬一有帳號被盜時的損害範圍。

• 第三部：部署 WAF (網站應用程式防火牆)

  WAF 就像是你網站的保全，站在第一線過濾所有進來的請求。許多知名的 WAF 服務 (如 Cloudflare) 都能夠辨識出常見的 SQL Injection 攻擊模式，並在它們到達你的網站前就直接攔截掉。這是一層非常有效的外部防護。

結論：安全是日常，不是口號

SQL Injection 雖然是個老派的攻擊手法，但它之所以歷久不衰，正是因為它利用了最基本的人性弱點：疏忽與便宜行事。無論你是開發者還是網站管理者，都不能對資安掉以輕心。

對開發者來說，把 $wpdb->prepare() 養成肌肉記憶，是你最基本的職業道德。對管理者來說，保持更新、謹慎授權、善用工具，是你守護網站資產的基本功。資安不是一次性的工作，而是一種持續的習慣與態度。希望今天的分享，能幫助你把網站的防禦工事做得更紮實。

如果你對於網站的安全性有疑慮，或是遇到了棘手的資安問題，不知道該如何下手。別擔心，浪花科技的團隊擁有多年的 WordPress 開發與維運經驗，能為你提供專業的資安健檢與解決方案。歡迎與我們聯繫，讓我們一起打造更安全的網路世界。

延伸閱讀

• 網站半夜被黑？別怕！資深工程師的 WordPress 終極安全指南，從預防到災難復原全攻略
• 你的表單安全嗎？揭開 WordPress Nonces 的神秘面紗，杜絕 CSRF 攻擊的終極防線！
• WordPress 安全不是單點防禦！資深工程師帶你構築「縱深防禦」三層鐵壁，駭客看了都搖頭