1) 本質與類型快速回顧#

• Stored XSS（儲存型）：惡意腳本被儲存在伺服器（如資料庫、留言板）並在其他使用者載入頁面時執行。
• Reflected XSS（反射型）：惡意輸入透過 URL 或表單即時反映在回應中，攻擊者誘導受害者點擊特製 URL。
• DOM-based XSS：攻擊在客戶端 JavaScript 操作 DOM 時發生，原始伺服器回應本身看似安全，但前端處理不當導致執行惡意程式。

2) 常見觸發場景#

• 把使用者內容直接插入 innerHTML、document.write、eval 等 API。
• 在未轉義的情況下把使用者輸入放到 HTML 屬性、事件處理器（onclick）、或 <script> 中。
• 動態構成 HTML 字串並插入 DOM（client-side templating 未做 escape）。

3) 防護策略（實務可執行）#

• 輸出編碼（Output Encoding）：在把資料輸出到 HTML、HTML attribute、JavaScript、CSS 或 URL 不同上下文時，採用對應的編碼函式。
  • HTML body → escape HTML（&、<、>、" 等）
  • HTML attribute → attribute-encoding（避免破壞引號）
  • JavaScript context → 使用安全接口或 JSON 序列化（不要直接拼字串）
  • URL context → URL-encode
• 使用框架的自動 escaping：例如大多數模板引擎（Mustache、Handlebars、Jinja2、React 的 JSX）會在輸出時自動 escape。不要關閉這些保護，除非非常必要並且清楚風險。
• 避免危險 API：盡量不要用 innerHTML, dangerouslySetInnerHTML, eval, new Function 等；若必要則在輸入經過嚴格白名單淨化。
• Content Security Policy (CSP)：透過 CSP 限制可執行的來源（script-src），並啟用 nonce 或 hash 機制來允許可信內嵌程式碼。CSP 不是萬靈丹，但能大幅降低成功攻擊面。範例 header：

  1
  Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<RANDOM>';
  

• HttpOnly 與 Secure Cookie：把 session cookie 設為 HttpOnly 避免被 JavaScript 讀取（降低 XSS 竊取 session 的風險）；Secure 強制僅在 HTTPS 傳輸。
• 輸入白名單（for rich text）：若允許富文本（HTML），使用安全的 HTML sanitizer（例如 DOMPurify、Bleach 等），並僅允許特定標籤/屬性與 URL schemes。

4) 範例（安全 vs 不安全，前端示意）#

不安全（示意）：

1
// Don't do this:
2
const container = document.getElementById('msg');
3
container.innerHTML = userInput; // userInput 含腳本 -> XSS

安全（示意）：

1
// Safer: use textContent or escape before inserting
2
const container = document.getElementById('msg');
3
container.textContent = userInput; // 不會當作 HTML 解析

或若必須插入 HTML，先用 sanitizer：

1
import DOMPurify from 'dompurify';
2
container.innerHTML = DOMPurify.sanitize(userInput);

5) 偵測與測試#

• 在開發階段加入自動化測試（SAST 與 unit tests for output encoding）。
• 使用 DAST 工具（OWASP ZAP、Burp）對輸入點做掃描（注意：僅在測試/授權環境執行）。
• 在瀏覽器 console 模擬 payload（安全情況下使用無害字串）確認應用如何處理特殊字符。

1) 本質#

CSRF 的攻擊者利用使用者已登入的瀏覽器權限（cookie、HTTP 認證等），誘導其瀏覽器向受信任網站發送未經授權的請求（例如轉帳、修改設定）。關鍵在於伺服器端無法分辨該請求是由真實使用者交互觸發還是外部網頁發起。

2) 被利用的常見場景#

• 任何以 cookie 認證的 state-changing action（POST/PUT/DELETE）如果沒有 CSRF 防護就容易被利用。
• 圖像/表單/GET 請求可能被當作觸發方式（例如 <img src="https://bank/transfer?to=...">）。現代 RESTful 設計通常要求 state change 使用非 GET 方法，但仍要防護。

3) 防護策略（實務明單）#

• CSRF Token（同源驗證 token）：在 server-rendered 或 SPA 與 server 互動時，對所有 state-changing 請求附帶不可預測的 token（伺服器驗證）；token 存於伺服器端 session 或在 cookie 與 request header 中雙向比對。
  • 例如：伺服器在表單頁面 embed 隱藏欄位 <input type="hidden" name="_csrf" value="...">。提交時伺服器檢查 token 是否正確。
• SameSite Cookie：把 cookie 的 SameSite 設為 Lax 或 Strict。Lax 在大多數情境對跨站 GET 請求有保護，而 Strict 更嚴格。此為簡單且高成效的保護。
• Double Submit Cookie：把隨機 token 同時放在 cookie 與 request body/header，伺服器端比較兩者是否一致（注意對 XSS 無效，因為 XSS 可讀 cookie）。
• 驗證 Referer/Origin：對於敏感請求，檢查 Origin 或 Referer header 是否屬於你的域（較可靠）。注意某些情況 referer 可能被瀏覽器隱藏或省略。
• 避免把敏感操作綁在 GET：務必把會改變狀態的操作用 POST/PUT/DELETE 並要求 CSRF token。

4) 範例（Express + csurf）#

伺服器端（Node/Express）：

1
import csurf from 'csurf';
2
const csrfProtection = csurf({ cookie: true });
3
app.use(cookieParser());
4
app.get('/form', csrfProtection, (req, res) => {
5
  res.render('form', { csrfToken: req.csrfToken() });
6
});
7
app.post('/process', csrfProtection, (req, res) => {
8
  // csurf 已驗證 token
9
});

1) 本質#

注入攻擊是指把惡意資料注入到原本應該是資料（而非指令）的位置，導致伺服器將資料錯誤當作程式或查詢的一部分執行。最常見的是 SQL 注入（攻擊者能操控查詢語句），但類似問題也發生在 shell command、LDAP、XML/XPath 操作等。

2) 常見場景#

• 直接把使用者輸入拼接成 SQL 字串："SELECT * FROM users WHERE id = " + req.query.id。
• 用輸入建構系統命令、shell 執行字串。
• 在動態構造 XPath、LDAP filter 時未過濾特殊字元。

3) 防護重點（實務面）#

• 使用參數化查詢 / Prepared Statements（最重要）：不要拼字串，使用 DB 驅動提供的 bind parameter 機制。資料會被視為參數而非 SQL code。
  • SQL 範例（Node + pg）：

    1
    const res = await client.query('SELECT * FROM users WHERE email = $1', [email]);
    

  • Java（JDBC）：

    1
    PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
    2
    ps.setInt(1, id);
    

• 使用 ORM 並了解其生成的 SQL：ORM 可以降低寫 raw SQL 的錯誤，但仍需留意動態 where clause 的拼接與 raw query 使用情況。
• 避免直接把使用者輸入傳給系統命令：若必須，使用安全 API（例如 spawn with args array 而非 shell string），並在可能時做白名單限制。
• 限制資料庫權限：應用使用的 DB 帳戶只給必要操作權限（SELECT/INSERT/UPDATE on specific tables），不要用 root 或 admin 帳戶執行日常查詢。
• 參考最小化表達式：避免把敏感查詢結果直接回傳至使用者，防止錯誤回傳洩露結構資訊。

4) 命令注入（Shell Injection）與防護#

• 不要把使用者輸入透過字串拼接放進 exec、system 等 shell command。改用參數化的 process spawn 或 libraries 並將不可信輸入當作資料傳入。
• 對於必須執行外部程序的情境，使用白名單與最小權限策略，並進行輸入長度及格式限制。