常見攻擊與防禦：注入、中間人、重放

情境：你的電商平台有多少漏洞？

你建了一個電商平台，功能都正常運作。但有人卻能：

• 搜尋商品時，把整個訂單資料庫倒出來
• 在商品評論區留下一段「炸彈」，讓每個看評論的人都中招
• 在公共 WiFi 偷聽你的客戶下訂單
• 把昨天一筆合法的退款請求重新發一次，再退一次錢

這些都是真實存在的攻擊手法。你不需要是資安工程師，但你要知道它們的存在。

---

SQL 注入：在點餐時夾紙條給廚師

原理

想像你去餐廳點餐，服務生把你的點單直接傳給廚師。有個壞客人在點單紙上偷偷加了一行小字：「並且把所有客人的信用卡資料也印出來。」

SQL 注入就是這樣：攻擊者在輸入欄位（搜尋框、登入表單）塞入 SQL 指令，讓資料庫執行他想要的查詢。

電商情境示範

假設你的商品搜尋 API：

如何防禦

參數化查詢（Parameterized Query）：不把用戶輸入直接黏進 SQL，而是用佔位符：

---

XSS：在評論區放炸彈

原理

XSS（Cross-Site Scripting，跨站腳本攻擊）：攻擊者在網頁的輸入欄位（評論、商品名稱）留下 JavaScript 程式碼，下次其他人瀏覽時就會執行這段程式碼。

電商情境示範

你的電商平台有商品評論功能。攻擊者留下這則評論：

所有之後看到這則評論的人，瀏覽器都會執行這段 JavaScript。

如何防禦

輸出時跳脫（Escaping）：把特殊字元轉成無害的 HTML 實體：

原始字元	跳脫後	說明
<	&lt;	讓瀏覽器顯示文字，不當標籤
>	&gt;	同上
"	&quot;	防止跳出屬性
&	&amp;	同上

現代前端框架（React、Vue）預設就會做跳脫，但要注意不要用 dangerouslySetInnerHTML 之類的功能直接輸出未過濾的內容。

---

中間人攻擊：咖啡廳的竊聽者

原理

你的客戶在星巴克用公共 WiFi 結帳。攻擊者在同一個 WiFi 網路上架設一個「監聽器」，可以看到所有沒有加密的網路流量——包括你客戶輸入的信用卡號、帳號密碼。

如何發生

客戶（手機）──── WiFi 訊號 ────► 攻擊者（監聽）──── 流量 ────► 你的伺服器

如果網站用 HTTP（沒有加密），資料是明文傳輸，攻擊者可以完整看到。

如何防禦

HTTPS = HTTP + TLS 加密。資料傳輸前先加密，攻擊者即使截到也只看到亂碼。

現在幾乎沒有理由不用 HTTPS：

• Let's Encrypt 提供免費憑證
• 搜尋引擎（Google）對 HTTP 降權
• 瀏覽器對 HTTP 網站標示「不安全」

---

重放攻擊：把合法請求重播一次

原理

攻擊者錄下一個合法的 API 請求，然後在之後重新發送這個請求。

電商情境示範

情境：退款 API

1. 客服人員發了一個合法請求：「退款訂單 #12345，$500 元」
2. 攻擊者（可能是內部人員）錄下了這個 HTTP 請求
3. 一小時後，攻擊者把同樣的請求再發一次
4. 系統以為是新的退款請求，再退一次 $500

如何防禦

時間戳 + Nonce（一次性隨機數）：

伺服器收到請求後，檢查：

1. 時間戳是否在合理範圍內（如 5 分鐘）
2. 這個 nonce 有沒有被用過（存在快取或 DB 裡）

---

四種攻擊快速對照

攻擊	比喻	攻擊目標	防禦方法
SQL 注入	在點單夾紙條給廚師	資料庫	參數化查詢
XSS	在評論區放炸彈	其他用戶的瀏覽器	輸出跳脫、CSP
中間人	咖啡廳竊聽者	傳輸中的資料	HTTPS
重放攻擊	把錄音重播一次	API 請求完整性	時間戳 + Nonce

---

練習題

---

AI 協作：學了這個，跟 AI 怎麼配合？

了解常見攻擊手法，讓你在 Code Review 或系統設計時，能提出正確的安全問題。

你的人類優勢：

• 你知道哪些功能涉及用戶輸入（評論、搜尋、表單）
• 你能判斷哪些 API 請求如果被重放會造成真實損失（退款、扣點）

可以這樣跟 AI 說：

我的電商平台有一個商品搜尋功能和評論功能。請幫我檢查以下程式碼有沒有 SQL 注入或 XSS 的風險，並建議修法：[貼上程式碼]