Cookie vs Session：為何 Session 更安全却仍可被劫持？

Web 應用透過 Cookie（客戶端、長效） 或 Session/會話 Cookie（伺服器端、登出即失效） 識別用戶。Session 難利用但非不可利用——關鍵在於取得有效 SessionID 並在會話結束前重放。

ASP.NET 環境下的 SessionID 機制

抓包可見 HTTP Request Cookie 欄位含 ASPSESSIONIDXXXXXXXX（X 為隨機字母）。伺服器以此值對應 Session 狀態。若攻擊者在管理員會話有效期內取得此值並攜帶請求，即完成冒充。

攻擊鏈：XSS 竊取 → 即時轉發 → 重放劫持

1. 尋找 XSS 點：案例中 WebAdmin 1.4（ASP.NET WebShell）目錄瀏覽 URL 存在跨站腳本漏洞。
2. 構造惡意載荷：注入 JavaScript document.cookie 讀取 SessionID 並立即 POST 至攻擊者收集端（如 cc.asp）。
3. 收集端即時利用：使用 ServerXMLHTTP 元件（支援伺服器端 HTTP 請求）攜帶竊取的 Cookie 訪問受保護功能（如檔案編輯查看 E:/MyWeb/webadmin.aspx），將回應存為本地 a.txt。
4. 驗證成果：訪問 a.txt 即見管理員視角頁面源碼；直接訪問收集端則獲登入頁（無 Session）。

關鍵難點與防禦

• 時效性：Session 會話極短，必須「即時轉發、即時利用」。
• 目標熟悉度：攻擊者需深知應用功能入口（如檔案編輯參數結構）。
• 防禦措施：
  • HttpOnly Cookie 禁止 JS 讀取 SessionID。
  • 嚴格輸出編碼修補 XSS。
  • Session 綁定 IP/User-Agent/裝置指紋。
  • 關鍵操作二次驗證（MFA/重輸密碼）。
  • 縮短 Session 逾時、強制輪換 SessionID。

結語

HTTP 會話劫持難度較高，需鏈接 XSS、即時重放、目標熟悉等多環節。但在技術領域，除複製代碼外，沒有不勞而獲的成果。開發者應建立「不信任任何輸入、預設最小權限、纵深防禦」的安全編碼文化。