SQL 注入
SQL 注入（SQL Injection）發生在應用程式把使用者輸入直接拼進資料庫查詢時。資料庫分不清哪一段是指令、哪一段是資料，於是輸入可能改變查詢的意義，造成資料外洩、竄改，甚至在設定極差時影響主機。
合法使用
對未授權網站嘗試注入，可能觸及刑法第 358、359 條。本頁只說明成因與正確寫法，不提供攻擊語句。
根因與正確作法
錯誤模式是字串拼接：把帳號、搜尋關鍵字接到 SELECT ... WHERE ... 後面。只要輸入裡出現查詢語法，語意就變了。
正確作法是參數化查詢（prepared statement）：先把查詢結構送給資料庫，資料用綁定參數另外傳，資料庫永遠當資料處理。物件關聯對映（ORM）若使用參數化 API，也是同一原理；若又把字串拼回去，防護就失效。
額外防禦：
- 資料庫帳號只給該應用需要的權限，不要用管理員連線。
- 對輸入做業務規則驗證（型別、長度），但驗證不能取代參數化。
- 錯誤訊息不要把 SQL 或表格結構顯示給使用者。
- WAF 可擋常見探測，但繞過手法很多，不能當唯一控制。
建議影片
OWASP Top 10 2021 - The List and How You Should Use It
注入在 2021 清單為 A03。這支概覽把注入放回「應用程式最常見風險」的位置，並強調要用清單排修補，而不是只記得名稱。細節請讀 OWASP 官方 A03 條目。
How NOT to Store Passwords!
注入常以「把帳密整表讀走」收場。Computerphile 說明為什麼密碼必須加鹽、用慢速雜湊儲存：即使查詢被濫用，對手拿到的也不該是明文。兩件事要同時做：查詢參數化，密碼雜湊正確。
官方學習資源
OWASP
A03:2021 Injection 與 SQL Injection Prevention Cheat Sheet 是開發實作的權威起點。