會話是什麼?

📌 去遊樂園買票，拿到一個手環，戴著它你可以一直玩，不用每次都重新買票

如果有人偷走或複製你的手環，他就能假裝是你，繼續使用你的票玩遊樂設施

會話管理就是管理手上手環的安全：要給誰、怎麼保護它、不讓別人複製或偷走

攻擊方

1. 偵察：找出會話憑證（cookie、localStorage、Authorization header）
2. 竊取憑證： XSS 偷 cookie、不安全的網路攔截（未用 HTTPS）、透過惡意 Wi-Fi 做中間人 (MITM)
3. 會話固定（Session Fixation）：讓受害者用攻擊者提供的 session id 登入（如誘導點擊特製連結），受害者登入後攻擊者用相同 id 存取
4. 會話重放（Session Replay）：重放已截到的 token/封包，重複執行有授權的操作
5. 劫持/橫向使用：用竊來的 session 進行金融操作或資料外洩

防禦方

1. 使用 HTTPS（強制 TLS）：所有 session token 在傳輸中必須加密，避免被攔截
2. Cookie 安全屬性：
   • Secure：只透過 HTTPS 傳送
   • HttpOnly：不能被 JavaScript 存取，降低 XSS 偷 cookie 的風險
   • SameSite（Lax / Strict）：減少 CSRF 與跨站重放的風險
3. 短存活期 + 適度續期（sliding expiration）：減少被竊取後可利用時間
4. 在重要操作要求 re-auth（step-up authentication）：例如提款或改密要二次驗證
5. 防範 session fixation：登入成功時強制重新產生 session id（不採用舊 id）
6. 對 JWT 的安全使用：
   • 不把敏感資料放在 JWT payload（即使加密也不推薦）
   • 設定短 expiry (exp) 並驗證 iat/nbf，簽名使用強演算法並妥善保管私鑰
   • 對登出/撤銷實作 token 黑名單或變更 token 的版本（token rotation）
7. 防 XSS 與 CSRF：XSS 會導致 cookie 被竊；CSRF 可在沒有竊取憑證的情況下濫用 session（而 SameSite 與 CSRF token 可防護）
8. 監控與異常偵測：偵測 session 在短時間內從不同地理位置或不同 device 同時使用、或大量敏感操作

常見漏洞

1) Cookie 未設 HttpOnly

• 情境：網站用 document.cookie 可以讀到 session cookie
• 危險：XSS payload document.cookie 可偷出憑證
• 修復：伺服器端設定 Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax

2) Cookie 未設 Secure（使用 HTTP）

• 情境：登入後頁面仍用 HTTP 或 cookie
• 危險：在公共 Wi-Fi 上可被 MITM 攔截
• 修復：強制 HTTPS

3) Session Fixation 範例

• 攻擊：攻擊者產生 session id sess=at123，目標用該 id 訪問並登入，攻擊者用 sess=at123 存取
• 修復：登入成功後伺服器產生新 session id，並廢棄舊 id

4) JWT 過長存活 / 未驗證 alg

• 問題：伺服器接受 alg: none 或弱簽名，或設定很長的 exp
• 危險：攻擊者可製造有效 token 或長期使用被盜 token
• 修復：只接受強簽名演算法、核查 exp/iat、短期 token 與 refresh token 機制

📌 exp → 過期時間

📌 iat → 記錄Token生成時間

偵測指標

• 短時間大量不同 IP 嘗試同一 session id
• 登入成功後立即刪除 cookie / 日誌或更動系統時間
• 大量敏感操作（轉帳、密碼變更）由同一 session 在短時內發生
• User-Agent 或 device fingerprint 突然變更

結論

📌 會話是應用與使用者之間的信任憑證

一旦被竊取或錯誤管理

攻擊者即可冒充使用者執行敏感操作

防禦必須從傳輸層（強制 HTTPS）

資料儲存與 cookie 屬性（HttpOnly、Secure、SameSite）

會話生命周期管理（短期、登入後重產生 id）

到應用層的 step-up 驗證與行為監控全面部署

📌 在網站上看到 Http:// 需特別注意