什麼是 Session Fixation？攻擊者如何劫持使用者工作階段

什麼是 Session Fixation？

Session fixation 是一種 Web 應用程式弱點，攻擊者可藉由利用工作階段識別碼管理失敗來劫持有效的使用者工作階段。其核心缺陷很直接：當使用者進行驗證時，應用程式不會指派新的工作階段 ID。這表示，若攻擊者知道或控制驗證前的工作階段識別碼，就能使用它存取已驗證的工作階段，就如同自己是合法使用者一樣。

MITRE CWE 對此弱點的正式定義為：「在驗證使用者，或以其他方式建立新的使用者工作階段時，若未使任何現有的工作階段識別碼失效，便會讓攻擊者有機會竊取已驗證的工作階段。」對您而言，其結果幾乎等同於完整的帳戶接管，而且受害者通常完全不知道發生了什麼事。

Session fixation 與 session hijacking 不同，儘管您可能會看到兩者被混淆。OWASP 清楚劃分兩者：session fixation 始於受害者登入之前，而 session hijacking 則發生在已存在有效且已驗證的工作階段之後。在 fixation 攻擊中，攻擊者已經知道工作階段 ID，因為那是他們設定的。在 hijacking 攻擊中，攻擊者必須從有效工作階段中擷取或預測工作階段 ID。

這項區別對您的安全控制很重要。若您的應用程式會在登入後重新產生工作階段 ID，便能阻止 fixation 攻擊。若它只會在傳輸過程中加密工作階段權杖，您處理到的是 hijacking，卻會讓 fixation 完全暴露。當您從機制層面理解這種攻擊如何運作時，就能明白這項差異為何如此關鍵。

Session Fixation 如何運作？

Session fixation 依循四步驟攻擊流程，且 MITRE CWE 與 OWASP WSTG 均有記錄。

• 步驟 1：取得工作階段。 攻擊者造訪目標應用程式並取得有效的驗證前工作階段 ID。例如，伺服器可能會回傳 JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1。在使用寬鬆工作階段接受機制的應用程式中，攻擊者可以提供任意的工作階段 ID 值，而應用程式會不加質疑地接受。
• 步驟 2：傳遞工作階段。 攻擊者將已知的工作階段 ID 傳遞給受害者。這種傳遞可透過精心構造的 URL、跨網站指令碼承載、注入的 META 標籤，或 HTTP 回應分割來進行。目標很簡單：讓受害者的瀏覽器在存取目標應用程式時送出由攻擊者控制的工作階段 ID。
• 步驟 3：受害者驗證。 受害者點擊精心構造的連結，或透過攻擊者的傳遞機制造訪應用程式，並正常登入。應用程式會驗證憑證並授予存取權。但它未能在成功登入時重新產生工作階段 ID，而是繼續使用攻擊者已知的相同識別碼運作。
• 步驟 4：帳戶接管。 攻擊者使用已知的工作階段 ID 向應用程式送出請求。伺服器會將這些請求視為來自已驗證受害者的請求。 MITRE 指出，這會在「工作階段存續期間，幾乎不受限制地存取受害者的帳戶」。

除了四個核心步驟之外，session fixation 還可依據攻擊者的存取能力與目標應用程式的組態，透過數種不同的方法進行傳遞。

五種主要攻擊向量

1. URL 參數注入 是最簡單的向量。攻擊者將工作階段 ID 嵌入為 URL 查詢參數，並透過網路釣魚或電子郵件傳送連結： https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID。 Burp Scanner 將「URL 中的工作階段權杖」歸類為 CWE-384。
2. 透過 XSS 的 Cookie 注入 使用在受害者瀏覽器中執行的 JavaScript 來設定工作階段 Cookie： document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE 確認 跨網站指令碼 是傳遞工作階段固定攻擊酬載的兩種最常見技術類別之一。
3. META 標籤注入 會植入一個指示瀏覽器設定 Cookie 的 HTML 標籤：<meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP 指出 這種方法比 JavaScript 注入更難防範，因為「在瀏覽器中不可能停用這些標籤的處理。」
4. HTTP 回應標頭注入 會利用回應分割弱點，將 Set-Cookie 標頭直接注入伺服器回應中，在不使用任何用戶端指令碼的情況下植入受控制的工作階段 ID。
5. 跨子網域 Cookie 固定 會利用共用網域架構。MITRE 對此有直接說明：如果 bank.example.com 和 recipes.example.com 共用相同的頂層網域，recipes 應用程式中的弱點就能固定一個工作階段 ID，而該 ID 將用於 example.com 上的所有應用程式。傳遞向量的廣泛性說明了為何你仍會在正式環境系統中看到工作階段固定攻擊。

工作階段固定攻擊的成因

工作階段固定攻擊的根本原因已有充分文件記錄，而每一項都代表你和開發團隊可以補上的缺口。

驗證後未重新產生工作階段 ID

這是主要原因，本文中的每個權威來源都有提及。該 OWASP 指南 直接指出：「當應用程式在使用者成功驗證後未更新其工作階段 Cookie 時，就可能存在工作階段固定弱點。」

該 OWASP 文件 指定在登入、密碼變更、權限等級變更及角色轉換時，必須重新產生工作階段 ID。該 CVE-2022-24895 記錄指出，Symfony 的 NONE 工作階段遷移策略會在驗證後保留相同的工作階段，從而使固定攻擊成為可能，且其嚴重性評等為 HIGH。

寬鬆的工作階段 ID 接受機制

OWASP Session Management Cheat Sheet 定義了兩種處理工作階段 ID 的機制。寬鬆機制會接受任何由使用者設定的工作階段 ID 值為有效，並為其建立新的工作階段。嚴格機制則只接受先前由應用程式產生的工作階段 ID。如果你的應用程式使用寬鬆機制，就等於讓攻擊者無須先取得伺服器簽發的 ID，便可植入任意值。

可預測的工作階段識別碼

MITRE 將可預測的工作階段識別碼視為促成條件之一，與 CWE-340（可預測數字或識別碼的產生）相關。當工作階段 ID 遵循模式或使用薄弱的隨機性時，攻擊者無須從伺服器取得有效值即可加以預測。

寬鬆的 Cookie 網域範圍

將 Domain Cookie 屬性設為頂層網域，例如 Domain=example.com 而非 Domain=app.example.com，會導致 Cookie 傳送至所有子網域。任何單一子網域中的弱點，都會成為該網域上每個應用程式的固定攻擊入口點。

未重新產生工作階段的 HTTP 到 HTTPS 轉換

OWASP WSTG-SESS-03 識別出此特定情境：網站透過 HTTP 發出工作階段識別碼，然後重新導向至 HTTPS 登入表單，但在驗證時未重新發出工作階段 ID，會使驗證前的 ID 暴露於網路層級的竊聽。攻擊者會透過不安全的連線擷取該 ID，並等待受害者完成驗證。這些成因很少單獨出現，而了解標準社群如何正式分類它們，有助於您溝通並排定修補的優先順序。

OWASP 對工作階段固定攻擊的分類

工作階段固定攻擊在三個權威標準系統中都有正式分類：MITRE Common Weakness Enumeration、OWASP Top 10，以及 OWASP Web Security Testing Guide。在 OWASP A07 之下，它屬於驗證失敗類別，與具有相同修補範圍的相關弱點並列。每種分類都服務不同受眾，並傳達不同的行動訊號。

CWE-384：正式弱點識別碼

MITRE CWE-384 是工作階段固定的主要分類，將此弱點定義為在未使現有工作階段識別碼失效的情況下驗證使用者。其在 MITRE 分類法中的概況：

• 弱點類型： 工作階段憑證類別中的基礎弱點
• 常見後果： 取得權限或冒用受害者身分；在工作階段存續期間完全接管帳戶
• 利用可能性： 中等 — 需要在登入前將已知的工作階段 ID 傳遞給受害者
• 平台範圍： 與程式語言無關；無論 Web 技術堆疊或框架為何皆適用
• CWE Top 25 狀態： 於 2019 年進入 Top 25；在 2023 年版本中仍是持續追蹤的活躍弱點

這些特性使 CWE-384 成為弱點掃描器與評估框架中的一致訊號，在這些框架中它會直接對應到以工作階段生命週期處理為目標的測試案例。

OWASP Top 10 與測試標準

CWE-384 對應到 A07:2025 — 驗證失敗，屬於 OWASP Top 10 中的一項。此分類帶有一項重要意涵：工作階段固定被視為驗證控制失敗，而非 Cookie 設定錯誤。這項區別明確指出，它應納入登入流程審查與驗證強化工作，而不只是 Cookie 設定稽核。

這四項參考資料合在一起，可為您提供詞彙、測試案例與修補指引，以便在任何既有安全計畫中處理工作階段固定問題。在建立分類脈絡後，值得進一步檢視當此弱點遭成功利用時實際會發生什麼情況。

工作階段固定的影響與風險

工作階段固定可在遭入侵的工作階段存續期間實現完整帳戶接管。一旦攻擊者持有已驗證的工作階段 ID，便可使用受害者擁有的所有權限進行操作：讀取敏感資料、發起交易、修改帳戶設定，以及在受害者具有管理權限時提升存取權限。

OWASP 分類與嚴重性

CWE-384 歸類於 OWASP A07。A07:2025 類別的平均加權可利用性分數為 7.69，對應到 共 7,147 個 CVE，涵蓋已測試的應用程式。對應到 A07 類別的 CVE 總數在 2021 與 2025 年版本之間也有所增加，反映出 攻擊面是擴大而非縮小。

CVSS 分數範圍

已確認的工作階段固定 CVE 橫跨 中度到重大。評分最高的案例通常涉及這類情境：在廣泛部署的驗證外掛程式或框架中，固定化可使未經驗證的帳戶遭到接管。對於身為實務工作者的您而言，有一個重要的細微差異：session fixation CVE 經常在 NIST NVD 與供應商 CNA 之間出現評分差異。例如，CVE-2019-17563 (Apache Tomcat) 從 NIST 獲得 CRITICAL 評級，但 Apache 則評估為「Low」，並將利用條件描述為「過於狹窄，難以形成實際可行的利用」。

加劇風險因素

工作階段固定很少是單獨存在的風險。CVE-2024-56529 (Mailcow) 顯示，只有在受害者瀏覽器停用 HSTS 時，攻擊才會成功。Microsoft Research 在 IEEE S&P 2015 發表的一篇論文記錄指出，Cookie 注入可在真實世界網站上繞過標準的工作階段重新產生防禦。當 縱深防禦 控制同時失效時，工作階段固定弱點可能迅速升級。誰會受到影響這個問題，不僅僅限於 Web 應用程式。

攻擊者如何利用工作階段固定

攻擊者會透過從目標式網路釣魚到機會式工作階段污染等各種情境來利用工作階段固定。

以網路釣魚為基礎的 URL 注入

攻擊者製作包含已知工作階段 ID 的 URL，並透過 網路釣魚 或 社交工程 傳送。該 URL 看起來合法，因為它指向真實的應用程式網域。受害者點擊連結、正常登入，並在不知情的情況下驗證了由攻擊者控制的工作階段。這是以 URL 為基礎傳送工作階段 ID 最常見的情境。

公共終端機利用

MITRE CWE-384 記錄了一個典型情境：攻擊者在公共終端機上建立工作階段、記錄工作階段識別碼、將瀏覽器重設為登入頁面，並等待下一位使用者進行驗證。應用程式會繼續使用預先存在的工作階段 ID，使攻擊者「在工作階段存續期間幾乎不受限制地存取受害者帳戶」。

非目標式工作階段污染

CVE-2022-30769 (ZoneMinder) 展示了一種攻擊，攻擊者可以「將工作階段 Cookie 污染給下一位已登入的使用者」。這不需要鎖定特定個人。遭污染的工作階段會由下一位完成驗證的人繼承。在監控平台等共用存取環境中，這種模式尤其危險。

競爭條件利用

CVE-2013-2067 (Apache Tomcat) 揭露了 FORM 驗證中的競爭條件。當受害者正在完成登入表單時，攻擊者可重複傳送對已驗證資源的請求，從而注入一個使用受害者憑證執行的請求。Apache 將其評為「Important」嚴重性。

跨子網域攻擊

在共用頂層網域的多應用程式架構中，攻擊者會利用低安全性的應用程式，將工作階段 Cookie 固定為父網域範圍。之後該網域上的所有其他應用程式都會接受這個固定的工作階段 ID。這種情境常見於在共用網域上執行多個內部工具的企業環境。了解誰會受到影響，有助於您決定應優先在哪裡尋找這些弱點。

誰會受到工作階段固定影響？

工作階段固定會影響任何透過識別碼管理使用者工作階段，且未在驗證時重新產生這些識別碼的應用程式。CVE 記錄與 MITRE 文件指出了數個結構上高風險的類別。

• 使用以 URL 為基礎之工作階段識別碼的 Web 應用程式 面臨最直接的暴露風險。以 URL 為基礎的工作階段傳輸讓攻擊者可透過精心構造的連結提供受控的工作階段 ID，而不需要額外的弱點。
• CMS 與驗證外掛程式生態系統 一再受到影響。CVE-2024-13279 (Drupal TFA，根據 CISA)、CVE-2010-1434 (Joomla!)、CVE-2012-5391 (MediaWiki) 與 CVE-2019-8116 (Magento) 都顯示，當未強制執行工作階段重新產生時，疊加在 CMS 平台上的驗證模組會引入關鍵的工作階段固定風險。
• J2EE/Java EE 應用程式 擁有記錄最廣泛的 CVE 系列之一。僅 Apache Tomcat 就涵蓋從 2013 到 2025 年的多個 CVE，包括 CVE-2013-2067、CVE-2014-0033、CVE-2015-5346、CVE-2019-17563，以及 CVE-2025-55668。
• 多應用程式共用網域架構 在設計上即存在弱點。具有租戶子網域的 SaaS 平台，以及共用頂層網域的企業應用程式組合，都面臨跨子網域固定風險，正如 MITRE 直接記錄的那樣。
• ICS/SCADA 平台 代表新興的風險面。CVE-2025-70973 (ScadaBR 1.12.4，於 2026 年 3 月揭露) 顯示工業控制系統平台中存在工作階段固定，這與 CWE-384 的 ICS 類別對應至 CWE-1364 (ICS Communications: Zone Boundary Failures) 與 CWE-1366 (ICS Communications: Frail Security in Protocols) 一致。
• 企業工作流程平台 也有已記錄的暴露情況。CVE-2022-38369 (Apache IoTDB) 與 CVE-2022-38054 (Apache Airflow) 顯示，工作流程自動化工具也無法倖免。受影響類別的廣泛性，使真實世界案例研究成為理解這些弱點在實務中如何出現的有用視角。

工作階段固定的真實世界範例

從企業 Java 框架到工業控制平台，各式各樣的正式環境系統都已確認存在工作階段固定。以下範例說明，相同的底層缺陷會如何依環境不同而呈現出不同樣貌。

Apache Tomcat FORM 驗證競爭條件 (CVE-2013-2067)

這仍然是影響最重大的 Tomcat 工作階段固定 CVE，由 Apache 評為「Important」。此弱點影響 Tomcat 6.0.21 至 6.0.36 以及 7.0.0 至 7.0.32，利用了 FORM 驗證中的競爭條件。當受害者完成登入表單時，攻擊者可重複傳送對已驗證資源的請求，注入一個使用受害者憑證執行的請求。諷刺的是，在驗證時變更工作階段 ID 的選項本身就是在 Tomcat 6.0.21 中加入的。此 CVE 代表 Tomcat 自身 固定防護中的一個錯誤。

Symfony 框架 CSRF 權杖繞過 (CVE-2022-24895)

Symfony 2.0.0 至 6.2.5 版本受到一個 高嚴重性弱點。該框架在登入時重新產生了工作階段 ID，但保留了其餘的工作階段屬性，包括 CSRF 權杖。這種部分重新產生使同站點攻擊者能夠透過工作階段固定變體繞過 CSRF 防護。教訓很明確：僅重新產生工作階段 ID 並不足夠。必須完整使工作階段失效並重新簽發。

ScadaBR 工業控制系統 (CVE-2025-70973)

於 2026 年 3 月揭露，ScadaBR 1.12.4 中的此漏洞遵循典型的工作階段固定模式。該應用程式會為未驗證使用者指派 JSESSIONID 工作階段 Cookie，且在成功驗證後不會重新產生工作階段識別碼。登入前建立的工作階段會在受害者登入後變成已驗證狀態。此 CVE 值得注意，因為它顯示 ICS/SCADA 環境中存在活躍的工作階段固定風險。

ZoneMinder 非定向工作階段污染 (CVE-2022-30769)

ZoneMinder 1.36.12 及更早版本 允許攻擊者污染工作階段 Cookie，而該 Cookie 會由下一位進行驗證的使用者繼承。這不需要鎖定特定受害者，因此在多名操作員共用同一平台存取權限的共享存取監控環境中特別危險。

PHP 工作階段採用 (CVE-2011-4718)

PHP 的工作階段模組是「採用式」的，這表示它會接受來自外部來源的工作階段 ID。該 PHP RFC 指出，若未同時啟用 session.use_strict_mode，「使用 session_regenerate_id() 無法防止工作階段採用/固定」。PHP 5.5.2 將 session.use_strict_mode 引入作為 修正，但即使啟用了 strict mode，自訂儲存處理常式仍可能存在漏洞。這些事件的完整歷史記錄顯示，此漏洞類別已持續存在多久。

工作階段固定時間軸與歷史

自 2002 年以來，工作階段固定就已有正式文件記錄，而 CVE 記錄顯示它在新舊程式碼庫中仍然活躍。以下時間軸追蹤關鍵揭露事件與框架層級的回應。

這條時間軸跨越二十多年，且沒有放緩跡象。工作階段固定不是歷史性漏洞。它持續出現在新的與舊有的程式碼庫中，從企業框架到 ICS 平台皆然。如果您知道如何檢視自己的應用程式，就可以採取下一步。

如何偵測工作階段固定

工作階段固定是較容易確認的漏洞之一：核心測試只需要在登入前擷取工作階段識別碼、完成驗證，並比較之後的值。以下方法涵蓋 手動驗證、Cookie 屬性檢查、自動化掃描，以及 WAF 層識別。

手動滲透測試 (OWASP WSTG-SESS-03)

權威性的測試程序來自 OWASP WSTG。對您而言，黑箱測試很直接。

1. 擷取驗證前的工作階段 ID。 造訪應用程式並記錄工作階段 Cookie 值 (例如，JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1)。
2. 在提交已擷取的工作階段 ID 的情況下進行驗證。 提交有效憑證，並附上原始工作階段 Cookie。
3. 比較工作階段 ID 值。如果伺服器在成功驗證後回傳相同的工作階段 ID，則該應用程式存在漏洞。

對於未完整採用 HSTS 的應用程式，WSTG-SESS-03 描述了第二種策略：從另一台機器將所有不是在登入後新簽發的 Cookie 強制送入受害者的瀏覽器，然後確認這些 Cookie 是否能在驗證後授予對受害者工作階段的存取權。

Cookie 屬性驗證

檢查工作階段 Cookie 中的強化指標。__Host- 前綴可提供對抗基於網路的工作階段固定的完整性保護。__Secure- 前綴表示部分強化。執行 WSTG-SESS-03 以驗證 HttpOnly、Secure 和 SameSite 屬性是否已正確設定。

DAST 掃描

OWASP ZAP 提供主動與被動掃描模式，並支援工作階段管理，包括處理 Cookie、權杖及其他機制。ZAP 對工作階段與驗證強制執行的分析可協助您找出 失效的驗證 以及工作階段固定錯誤。Burp Suite Professional 涵蓋工作階段管理測試工作流程，可作為適用於工作階段管理測試的動態 Web 漏洞掃描器。

基於 WAF 的識別

該 OWASP 文件 指出，ModSecurity 結合 OWASP Core Rule Set 可提供對抗工作階段固定攻擊的對策。此 WAF 層方法 建議用於原始碼不可用、無法修改，或實作完整應用程式層修補需要大幅重新設計的情況。有效的審查應直接導向預防，而所需控制措施已有明確定義。

如何防止工作階段固定

預防的核心在於一項不可妥協的要求：應用程式必須在每次驗證事件時簽發新的工作階段 ID，並拒絕任何不是由伺服器本身產生的工作階段識別碼。以下控制措施從應用程式層、框架層級、Cookie 設定與網路架構來滿足該要求。

應用程式層控制措施

• 在驗證後重新產生工作階段 ID。 這是最重要的單一控制措施。OWASP WSTG-SESS-03 清楚說明了此要求：「應用程式在驗證使用者之前，應一律先使現有的工作階段 ID 失效；若驗證成功，則提供另一個工作階段 ID。」在每次權限層級變更時都必須重新產生，包括登入、密碼變更、權限變更與角色轉換。
• 使用嚴格的工作階段管理。 將應用程式設定為僅接受由伺服器產生的工作階段 ID。拒絕由用戶端提交的任意工作階段 ID 值。PHP 在 5.5.2 版中專門為此目的引入了 session.use_strict_mode。
• 完全使工作階段失效。 CVE-2022-24895 (Symfony) 證明部分工作階段重新產生並不足夠。在保留其他工作階段屬性（例如 CSRF 權杖）的同時重新產生工作階段 ID，會造成殘留漏洞。必須完整使工作階段失效並重新簽發。

框架特定實作

Spring Security 會在使用者登入時建立新的工作階段或變更工作階段 ID，藉此自動防範工作階段固定攻擊。提供四種可設定的策略： changeSessionId() （建議使用）, migrateSession()、newSession()，以及 none()（不建議使用）。

Cookie 安全性設定

遵循 NIST SP 800-63B 要求：

• Secure 旗標：必須設定（Cookie 僅透過 HTTPS 傳輸）
• Domain 和 Path：必須限制在實務上最小的範圍
• HttpOnly 旗標：應設定（防止 JavaScript 存取）
• SameSite=Lax 或 Strict：應 設定（依據 NIST SP 800-63B v4 草案）
• __Host- 前綴搭配 Path=/: 應設定（依據 NIST SP 800-63B v4 草案）

結合套用這些旗標可防止最常見的網路型與跨網站固定攻擊傳遞情境，並大幅提高任何嘗試進行 Cookie 注入的攻擊者門檻。

架構層級控制

不要在相同網域上混用不同安全等級的應用程式。實作包含子網域在內的完整 HSTS，以對抗基於網路的固定攻擊。在無法立即進行應用程式層級變更時，部署搭配 OWASP Core Rule Set 的 ModSecurity，以提供 WAF 層級保護。若有適當工具支援，預防與審查的效果最佳。

偵測與預防工具

識別並阻止工作階段固定攻擊需要涵蓋三個層級的工具：模擬真實攻擊條件的動態掃描器、在程式碼層級強制執行安全預設值的框架原生保護，以及可攔截已進入已驗證工作階段之固定攻擊型入侵的行為分析。以下工具涵蓋這三個層級。

DAST 與滲透測試工具

• OWASP ZAP 是一款免費的、開源的動態應用程式安全測試工具。根據 官方文件，ZAP 使用主動與被動掃描模式來尋找工作階段管理缺陷，包括工作階段固定攻擊。
• Burp Suite Professional 提供 工作階段測試工作流程與掃描器規則，用於識別工作階段權杖處理弱點。其手動測試功能可讓您在完整檢視請求/回應的情況下，逐步執行 WSTG-SESS-03 程序。
• ModSecurity with OWASP Core Rule Set 提供 WAF 層級的工作階段固定攻擊對策，包括識別並強制執行安全 Cookie 屬性、黏性工作階段追蹤，以及在觀察到權限變更時更新工作階段 ID。

框架安全功能

Spring Security 內建的工作階段固定攻擊防護、PHP 的 session.use_strict_mode 和 session_regenerate_id()，以及 ASP.NET's Session.Abandon() 都提供語言原生的防護。您應驗證這些功能已在您的部署中啟用並正確設定，而不是依賴預設設定。

相關弱點

Session fixation 並非獨立運作。數個密切相關的弱點與 CWE-384 共享傳遞機制、利用條件或風險放大因素。將它們作為一個整體來理解，比僅處理 session fixation 更能形成更強健的修補範圍。

• 跨網站指令碼 (CWE-79) 可作為 session fixation 的傳遞機制。反射型 XSS 可注入 JavaScript，在受害者的瀏覽器中設定受控制的工作階段 Cookie。處理 XSS 可封堵主要的 fixation 傳遞管道之一。
• 跨網站請求偽造 (CWE-352) 常與 session fixation 混淆，但其運作機制不同。CSRF 會利用瀏覽器自動傳送 Cookie 的特性，從已驗證的工作階段偽造請求。它不需要攻擊者知道或控制工作階段 ID。CWE-352 在 2023 CWE Top 25中排名第 9。
• 不當驗證 (CWE-287) 與 session fixation 密切相關，兩者同屬於 OWASP A07 驗證失敗類別。CWE-287 涵蓋所有形式的驗證失效，並在 2023 CWE Top 25 中排名第 13，在 CISA Known Exploited Vulnerabilities 目錄中有 10 筆條目。
• 工作階段到期時間不足 (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) 會延長固定工作階段 ID 保持有效的時間窗口，因而放大 session fixation 風險。較長的工作階段逾時時間會讓攻擊者有更多時間利用固定工作階段。
• 可預測數值的產生 (CWE-340) 可透過 MITRE 分類法中的 CanFollow 關係先於 session fixation 發生。可預測的工作階段識別碼會降低 fixation 攻擊的門檻，因為這使得猜測有效的工作階段 ID 值成為可能。孤立地處理 session fixation 很少能涵蓋完整的風險面；在同一週期中檢視這些相關弱點，可彌補 fixation 用來取得初始立足點的缺口。

相關 CVE

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

結論

Session fixation 利用的是單一且廣為人知的失敗點：您的應用程式在驗證後未重新產生工作階段 ID。它正式歸類為 CWE-384，並對應至 OWASP Top 10 2025 A07，且持續出現在 CMS 平台、Java 框架、PHP 應用程式以及 ICS/SCADA 系統中。 

您可透過在每次權限變更時輪替工作階段 ID、強制執行嚴格的工作階段接受規則、強化 Cookie 範圍，以及檢視驗證後活動是否遭濫用，來降低風險。