MFA, FIDO and Session Hijacking 簡單介紹

驗證因素

傳統會聽到有三個驗證因素：

1. 你知道什麼：
   1. 密碼
   2. PIN 碼
2. 你擁有什麼 (Something you Have)：
   1. 手機（作為接收短訊或推播通知的裝置），接收 OTP 一次性密碼 or SMS 驗證訊息
   2. 實體安全金鑰（Hardware Security Key）當使用者嘗試登入時，需要插入或靠近裝置來完成驗證。這些金鑰通常支援FIDO (Fast IDentity Online) 標準
3. 你是誰 (Something you Are)：
   1. 指紋
   2. 臉部

現在可以擴展到更多的要素，像是

1. 你在哪裡：例如系統會檢查你嘗試登入的 IP 位址或 GPS 位置
2. 你做什麼/行為模式 (Something you Do / Behavior)

FIDO 歷史

UFA

2010 前，我們很常使用 Password + OTP/SMS，但這種方式很容易被釣魚。

主要問題是，這邊的兩個因子都需要輸入。因此在 2012 UFA（Universal Factor Authentication）推出，FIDO Alliance 成立，目標是讓第二因子不需要輸入，因此使用實體金鑰，每個網站在硬體金鑰上面有一個 Key，使用的時候使用者只需要按一下硬體金鑰。

U2F

UFA 只是簡單的講說要用硬體金鑰，而 2014 年，FIDO 推出 U2F 標準（Universal 2nd Factor）。

主要原因是因為 UFA 使用 Challenge-Response 安全認證機制，但還是會受到攻擊者偷取 Response 並即時轉送的問題 (Real-Time Phishing/MITM)，因此 U2F 提出一些機制來解決問題：

1. 把上下文加上來，像是 Origin Binding，每個網站都有自己的 Challenge，因此不能被釣魚到假的網站
2. Per-Origin Key Pair，攻擊者拿到 response 也不能轉用到其他網站
3. Browser as Trusted Computing Base（TCB），只有瀏覽器能跟硬體金鑰說話 JS 無法指定 origin JS 無法直接操作 key
4. User Presence（物理互動驗證）：每次簽章都必須有人類動作（Touch）

FIDO2

FIDO U2F 只是讓第二因子變成強因子，第一因子還是密碼，因此 FIDO2 推出，讓硬體金鑰第二因素變成主因素，使用生物因子來當作第二因素，因此不需要密碼。

並且 U2F 不是 Web 標準，FIDO2 直接變成 W3C 標準，整合進所有瀏覽器，也變成 JS API()。

之前 U2F 的驗證器是外部的硬體金鑰，FIDO2 直接讓每台裝置都是驗證器，金鑰可以存在裝置內部安全模組，像是 Windows TPM, Android TEE …。

特點： 如同我們剛剛討論的，這是為了防釣魚。Google 早在 2017 年就強制 8 萬多名員工全部使用實體金鑰，之後就再也沒發生過員工帳號被釣魚成功的案例。

FIDO2 有不同標準：

• WebAuthn: 瀏覽器和作業系統的開放標準，讓網站能直接使用 FIDO 驗證器。
• CTAP (Client to Authenticator Protocol): 讓瀏覽器/OS 與外部驗證器 (如 USB/NFC/BLE 金鑰) 溝通的協議。 U2F 包含在 FIDO2 中: U2F (現稱為 CTAP1) 已經整合到 FIDO2 規範裡，確保舊的 U2F 裝置仍能與 FIDO2 系統協同工作。

FIDO2 相關研究

• Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols：攻擊者可以利用社交工程誘使用戶放棄 FIDO/U2F，而選擇這些弱驗證方式，從而讓釣魚（AiTM/實時釣魚）恢復可行。這就是所謂的 “FIDO downgrade attack（FIDO 降級攻擊）”
• CTRAPS: CTAP Client Impersonation and API Confusion on FIDO2：FIDO2 的標準可能還是有漏洞，上面的論文集中分析 CTAP（Client to Authenticator Protocol） 的安全與隱私問題
• A Security and Usability Analysis of Local Attacks Against FIDO2：此篇論文分析本地攻擊（如惡意瀏覽器擴充功能）如何損害 FIDO2
• Passwords and FIDO2 Are Meant To Be Secret (arXiv 2025)：針對攻擊者可利用XSS 或惡意程式腳本竊取密碼與 FIDO2 操作的場景。提出一種在瀏覽器中更安全地保護密碼與 FIDO2 認證通道的方法

Session Hijacking

FDO2 主要保護的是「登入階段（Authentication）」。Session Hijacking 則是攻擊者偷取或竄改已建立的會話憑證（Session Cookie / Token / JWT），攻擊者偷取或竄改已建立的會話憑證已登入的 session 被攻擊者利用，進行未授權操作。

1. Cookie 是一種由伺服器傳送給瀏覽器，並儲存在本地的小型文字檔。在 Session 管理中，它通常存放的是一個隨機的 Session ID
   • 支援 HttpOnly 屬性：這是防禦 XSS 偷取 Token 的最強防線。開啟後，JavaScript 無法讀取該 Cookie
2. JWT 是一種開放標準（RFC 7519），它將資訊加密或簽章後直接交給客戶端持有。狀態儲存在客戶端（Stateless）。伺服器不紀錄 Session，而是透過驗證 JWT 內的簽章（Signature）來確認合法性。
3. 「Token」是一個廣義詞，但在現代網路開發中，通常指 OAuth 2.0 中的 Access Token（如 Bearer Token）。

即便使用者用了最強的 MFA（如硬體金鑰 FIDO2），一旦登入成功後的 Session Token 被偷走，MFA 就形同虛設。」

攻擊分成兩個步驟

1. 壞人偷取 Token
2. 壞人使用 Token

壞人偷取 Token

針對偷取 Token 有不同的偷取方式：

1. 瀏覽器擴充功能竊取 (Malicious Extensions): 這是近年最主流且隱蔽的手段。擴充功能擁有極高的權限，可以繞過 HttpOnly 限制，直接透過瀏覽器 API 讀取所有 Cookie
   • Towards Browser Controls to Protect Cookies from Malicious Extensions 2024 論文揭露了現有瀏覽器完全無法阻止擴充功能讀取敏感 Cookie 的困境
2. 惡意軟體（如 Redline, Racoon Stealer）掃描用戶電腦中瀏覽器的資料夾（例如 Chrome 的 Login Data 或 Cookies 資料庫）
3. 利用 XS-Leaks（Cross-Site Leaks）或其他側向通道攻擊，觀察瀏覽器在加載受保護資源時的時間差或記憶體反應，進而獲取或預測 Session ID
4. 同站與跨子域攻擊 (Same-Site & Subdomain Attacks)，如果同一個主域名下的其他子域名被攻破，Token 仍會外洩
   • 攻擊者利用 a.example.com 的 XSS 漏洞，去讀取或覆蓋 example.com 的 Cookie。或者是利用瀏覽器對 Cookie 處理的不一致性（Inconsistency）來達成。

防禦方式可能包括：

1. Manifest V3 權限限縮： Chrome 強制推行的擴充功能規範，限制了跨域請求的能力，並要求更細顆粒度的權限申請（例如只能存取特定網站的 Cookie，而非全網域）。
2. BrowserOnly 屬性 (新提案)： 這是 2024 年論文《Towards Browser Controls to Protect Cookies from Malicious Extensions》提出的核心建議。這是一個新的 Cookie 屬性，一旦標記為 BrowserOnly，瀏覽器會從底層禁止任何擴充功能存取該 Cookie，即便該擴充功能擁有 cookies 權限也無法讀取
3. CHIPS (Cookies Having Independent Partitioned State)： 又稱 Partitioned 屬性。它會讓 Cookie 與「頂級站點」綁定。
   • 例子：如果 a.com 嵌入了 b.com 的 iframe，b.com 獲取的 Cookie 將被隔離在 a.com 的分區下，其他網站（如 c.com）無法透過側向通道窺探到這個分區的狀態
   • Fetch Metadata (Sec-Fetch-*)： 伺服器端檢查請求標頭中的 Sec-Fetch-Site 和 Sec-Fetch-Mode。如果發現一個原本應該由用戶手動點擊的資源，卻是由跨站腳本（Cross-site）以異常方式請求，則拒絕回傳資料，防止時間差攻擊
4. __Host- 前綴，這是目前防範子網域攻擊的最強手段

大部分防禦方式都是針對異常用 Token 行為，如下。

壞人用 Token

可能的防禦方式包含：

1. 限制 Session window 時間
2. 偵測到異常行為，強制重新登入 (你可能被偷走 Session 了)
3. 環境特徵驗證 (Context-Aware Verification): 透過收集客戶端的「環境指紋」來判斷使用者是否發生異常變更。
4. 會話綁定 (Session Binding / Token Binding): 最有名的是 Google 在 2014 提出的　DBSC (Device Bound Session Credentials)，它是一種 把 session 與特定裝置綁定的防護機制，讓使用者登入後的 session 不僅僅依靠 cookie，而是同時結合了與裝置相關的公鑰／私鑰對。
   • 在登入時 瀏覽器會為這次 session 生成一組公鑰／私鑰對
   • 私鑰保存在本地裝置（理想情況下由 TPM / Secure Enclave 等安全模組保護）
   • 網站伺服器保存相應的 session 公鑰，並在 session 期間要求瀏覽器證明其對私鑰的擁有權
   • 這樣即使攻擊者偷到了 cookie，沒有私鑰就無法在其他裝置上利用它登入
5. App-Bound Encryption (Chrome 最新防禦)： Google 近期在 Windows 平台上推出的機制。瀏覽器會利用系統服務（如伺服器端的 SID）將加密金鑰與「瀏覽器程式本身」綁定
   • 效果：即便惡意軟體偷走了 Cookies 資料庫，由於解密金鑰只能由「合法的 Chrome 程序」調用，惡意軟體無法在自己的進程中解開加密資料

相關研究

A Study of Multi-Factor and Risk-Based Authentication Availability 這篇論文作者們選取了 Top 5000 的熱門網站 並從中找出 208 個可建立帳戶的網站，然後模擬明顯的帳號盜用 / 劫持嘗試，觀察網站是否阻止這種未授權嘗試。

最後發現大多數網站並沒有真正提供足夠的防禦措施，以抵抗現實中常見的攻擊。