TS Cookie

在檢查Cookie時發現了TS開頭的的Cookie，紀錄一下這是什麼類型的cookie。

1. 什麼是 TS Cookie？

TS Cookie（常見前綴 TS…）是 F5 BIG-IP ASM（Advanced WAF）所使用的一種驗證型 cookie。
目的不是代表「使用者已登入」，而是用來驗證「這個瀏覽器 / 請求是否可信任」，以防止自動化攻擊、機器人、replay、某些類型的資料竄改等。
(這在鐵人賽的文章也有提到，之後會將文章移來這邊)

常見用途包含：

• 瀏覽器驗證
• 確認 client 能執行 injected JS（用來阻擋簡單 bot）
• 防replay或 request fingerprinting
• 協助 WAF 做初步風險判斷（是否允許請求進入後端）

2. TS Cookie 與登入 cookie 的主要差別

3. TS Cookie 的運作流程

使用者或自動化程式第一次請求網站。
ASM 以 HTML/JS 注入或在回應 header 設置 Set-Cookie 要求瀏覽器執行驗證（通常會注入一段 JS 來計算或簽發 cookie）。
瀏覽器執行 JS，產生或回填 TS Cookie（如 TS01234567=…）。
後續請求帶上 TS Cookie，WAF 檢查 cookie 是否有效（檢查簽章、時間戳、指紋等）。
驗證通過 → 請求被轉送到後端；驗證失敗 → 阻擋 / 轉驗證頁 / 重導。

• 所以流程上，TS Cookie 驗證通常發生在到達後端之前，而後端才會處理（或拒絕）登入 session 的檢查。

4. TS Cookie 裡面通常包含什麼？

TS Cookie 的實際 payload 是加密/簽章或編碼過的（不可直接逆向）。常見會包含或衍生自：

• 指紋資訊（User-Agent、Header 組合）
• 時間戳（timestamp）
• 來源 IP 或會話識別資訊（或雜湊）
• 防重放 token / nonce
• 驗證簽章（HMAC/簽名）

注意：實際格式由 F5 實作決定，通常不可逆、不可輕易偽造。

5. 常見情境

• A：掃描器被 WAF 阻擋或不斷重導向驗證頁面

原因：掃描工具沒有執行頁面 JS，拿不到 TS Cookie。
處理：
- 用能執行 JS 的工具（headless Chrome / Puppeteer / Selenium / Burp 的 embedded browser）
- 手動在瀏覽器先取得 TS Cookie，然後把 cookie 加到掃描器的請求上（simulated replay）
- 若為測試環境，可暫時放寬 WAF 的 browser verification（正式環境慎用）
- 但要跟客戶溝通到這邊比較麻煩(窗口不是開發者，也不一定懂我們要做什麼)

• B：多機器或負載平衡下驗證失敗

原因：不同 node 未同步 cookie 驗證或 session info。
處理：
- 啟用 cookie/session sync（或讓 ASM 走同一個處理 path）
- 檢查 F5 設定是否為 single point of verification(問窗口)

• C：看不出是哪個 cookie 在阻擋

處理：
- 清除所有 cookie，只留下 session，測試行為；再反過來只留 TS，逐一排查
- 檢查 response header 的 Set-Cookie 以判別是哪個端（WAF 或 app）在設定 cookie

6. 碰到阻擋時的實際建議

自動化掃描器若不執行頁面 JS，多半拿不到 TS Cookie，會被 WAF 阻擋或遭遇不必要的 false positives。

建議工具：
- 能執行 JS 的 headless browser（Puppeteer / Playwright / Selenium）
- Burp 的 Embedded Browser（或 Burp + Selenium）

測試：
- 以真實瀏覽器流程先取得 TS Cookie + session cookie。
- 將兩個 cookie 加到掃描器請求中（重放/回放）。
- 若需全自動化，寫 script 先用 headless chrome 做 login + js 驗證，再取得 cookie 並把 cookie 作為後續 API / 掃描用。

實際上之前碰到被阻擋的狀況時是靠客戶調整WAF才能連線上……這邊建議要是做案子前能跟客戶確定好就不用在這上面花時間溝通。