網站上線三個月，資料庫多了三萬筆陌生 email：SQL 注入攻擊的真實災情

那是個普通的週二下午，工程師小陳（化名）正在檢查網站流量異常，卻發現 Google Analytics 的推薦流量暴增——仔細一看，伺服器資料庫多了 30,000 筆陌生 email，全是看起來隨機產生的字串。攻擊者沒有用什麼高深的零日漏洞，只是用了最古老的 SQL 注入（SQL Injection）。

這個案例不是特例。根據 OWASP 2024 年的調查，SQL 注入依然是 web 應用程式最常見的資安漏洞前三名，而且在 AI 時代，這個問題反而更嚴峻了。

SQL 注入的原理：你的查詢被「夾帶私貨」
SQL 注入的原理說穿了很簡單：攻擊者在輸入框填入特殊的字元，讓原本預期的 SQL 查詢被「夾帶私貨」。

正常登入：使用者輸入帳號 john、密碼 pass123，後端組出這樣的查詢：

SELECT * FROM users WHERE username = 'john' AND password = 'pass123'
SQL 注入攻擊：帳號輸入 ' OR '1'='1 --，密碼隨便填，後端組出：

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = 'whatever'
-- 在 SQL 是註解符號，後面的密碼驗證全部被忽略。攻擊者就這樣用管理員身份登入系統了。

2026 年 SQL 注入的三個新威脅場景

場景一：電子商務平台價格劫持
攻擊者在結帳頁面的優惠碼欄位輸入惡意指令，如果系統沒有做好輸入過濾，這個惡意查詢就會把暢銷商品的價格改成 1 元。等受害者發現時，可能已經損失了數十萬營業額。

場景二：AI 客服機器人成為放大器
現在很多網站整合了 AI 客服。這類系統常會把對話內容存入向量資料庫，攻擊者刻意在對話中夾帶 SQL 注入語法，如果系統在呈現 AI 回覆時沒有做好輸出過濾，這些惡意指令可能被再次執行，造成「二次注入」。

場景三：第三方套件的隱形地雷
開發者習慣性地 npm install 或 composer require，卻很少仔細檢查套件的原始碼。根據 Sonatype 2025 年的研究，平均一個 Node.js 專案依賴超過 1,000 個套件，其中約 3% 存在已知資安漏洞，SQL 注入相關佔了不小的比例。

三道防線：從根本杜絕 SQL 注入
防線一：參數化查詢（Prepared Statements）
杜絕 SQL 注入最根本的方式，就是用參數化查詢。這種寫法確保使用者輸入永遠被當成「資料」而不是「指令」的一部分。

// Node.js + PostgreSQL
const query = 'SELECT * FROM users WHERE email = $1';
const result = await pool.query(query, [userInput]);
無論 userInput 填入什麼鬼東西，資料庫只會把它當成字串處理，沒有任何指令會被執行。這是基本功，沒有任何理由不用。

防線二：輸入驗證 + 輸出編碼
參數化查詢解決了大部分問題，但輸入驗證依然是必要的防御層。實務上建議同時做到兩件事：

輸入端：白名單驗證。email 欄位就只允許符合 email 格式的字元；數字欄位就只允許數字。不要靠「阻擋特殊字元」的 blacklist 方式，黑名單永遠漏洞百出。
輸出端：HTML 編碼。如果你的系統會把資料庫內容顯示在網頁上，輸出時務必做好 HTML 編碼，把 <、>、& 等字元轉成安全的形式。
防線三：最小權限原則 + 異常監控
最後一道防線是假設前線已經被突破。資料庫帳號的權限要最小化——應用程式帳號絕對不應該有 DROP TABLE 或 TRUNCATE 的權限。同時建立異常查詢的監控機制，及時發現攻擊行為。

結語

SQL 注入攻擊已經存在超過二十年，依然年年造成重大資安事故。2026 年的新變數是 AI 輔助開發流行、向量資料庫應用增加，讓攻擊面又擴大了。但基本的防治原則沒有變：參數化查詢 + 輸入驗證 + 最小權限。做好這三件事，SQL 注入的威脅就會大幅降低。

如果你想了解網站上線後還有哪些技術細節會影響網站表現，歡迎參考我們整理的 網站遷移與 301 轉址完整攻略，以及 Prompt Injection 資安實戰指南。