Injection 的核心問題其實只有一句話：系統把原本應該只是「資料」的東西，誤當成了「指令」。OWASP 也將 Injection 描述為不可信資料被送進 Interpreter，進而改變原本預期的操作。

想像餐廳讓客人在點餐單上寫備註，廚房卻沒分清「不要香菜」和內部工作指令。問題不在客人會寫什麼，而是系統根本沒有把「客人的資料」和「自己的命令」分開。

同一張紙條，交給不同的人，就變成不同的 Injection。

SQL Injection｜交給資料庫
外部輸入被拼進查詢語句，可能改寫查詢邏輯。防線是參數化查詢（Parameterized Query），讓 SQL 結構與資料分離。

Command Injection｜交給作業系統 Shell
輸入被當成命令的一部分，可能執行額外指令。應盡量避免直接呼叫 Shell，並嚴格限制可接受的參數。

Template Injection｜交給模板引擎
若使用者輸入被當成 Jinja2、Twig 等模板的一部分解析，可能從單純產生網頁一路擴大成伺服器端程式執行。關鍵是別讓外部輸入進入模板本身。

Log Injection｜交給日誌與解析工具
看似只是寫紀錄，但未處理的輸入能讓攻擊者在你的日誌裡「寫小說」——偽造事件、掩蓋行為，讓事後調查得出錯誤結論；日誌往往還會再送進 SIEM 或分析平台，也就是下一個 Interpreter。可用輸出編碼與結構化日誌（如 JSON）降低風險。

Prompt Injection｜交給 LLM
同樣是混淆資料與指令，但自然語言沒有 SQL 那種明確的語法邊界，無法靠「參數化自然語言」一招解決。這也是為什麼這個老問題到了 AI 時代反而更難處理。

所以防 Injection 不能只背「過濾特殊字元」。資料庫、Shell、模板引擎、Log Parser、LLM 各有自己的解讀方式，真正要問的是：

這份外部資料，下一站會交給誰解讀？

防禦的關鍵，是在每一道 Interpreter 邊界上，讓資料永遠只是資料。

延伸閱讀

• William G. J. Halfond, Jeremy Viegas & Alessandro Orso, A Classification of SQL-Injection Attacks and Countermeasures, ISSSE 2006。整理 SQL Injection 的類型，以及主要的偵測與防禦方法。
• OWASP, Injection Prevention Cheat Sheet。SQL、OS Command 等 Injection 的共同防禦原則。
• OWASP, LLM Prompt Injection Prevention Cheat Sheet。針對 LLM 應用的 Prompt Injection 緩解建議。