Session Fixation

在未使任何現有階段作業識別碼無效的情況下驗證使用者，會讓攻擊者有機會竊取通過驗證的階段作業

Session Fixation 弱點會在以下情況中出現：

1.Web 應用程式驗證一個使用者時，事先沒有使現有階段作業失效，而繼續使用已經與使用者相關聯的階段作業。
2.攻擊者可奪取使用者的階段作業識別碼，所以，在使用者驗證之後，攻擊者就可以存取驗證的階段作業。

在一般情況下，攻擊者會利用 Session Fixation 弱點，在 Web 應用程式中建立一個新的階段作業，並記錄關聯的階段作業識別碼。接著，攻擊者會讓受害者使用該階段作業識別碼驗證伺服器，這樣一來，會讓攻擊者透過作用中的階段作業取得存取使用者帳戶的權限。

有些架構 (例如 Spring Security) 在建立新的階段作業時，會自動使現有階段作業無效。若不採取此行為，應用程式會容易遭受此類攻擊。

範例 1：以下範例顯示受 Spring Security 保護之應用程式的片段，其中 Session Fixation 保護已停用。

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

即使是易受攻擊的應用程式，此處說明的特定攻擊是否會成功取決於數個受攻擊者青睞的因素：存取未受監視的公用終端機、讓已受攻擊的網路連線保持繼續運作的能力、被吸引登入公用終端機上易受攻擊應用程式的受害者。在大多數情況下，只要肯花時間，前面兩個因素是可以克服的。只要網站有趣，不難找到使用公用終端機、也有興趣登入到易受攻擊的應用程式的受害者。網站越不受歡迎，那麼使用這個公用終端機的人就會越少，這樣一來，前述攻擊成功的可能性也越低。

攻擊者攻擊 Session Fixation 弱點所面臨的最大挑戰是：誘導受害者使用攻擊者已知的階段作業識別碼來驗證易受攻擊的應用程式。在 Example 1 中，攻擊者使用直接明顯的方法並不高明，對於攻擊知名度較低的網站並不適用。但是，千萬不要過於大意，攻擊者有許多手段來突破上述攻擊的限制。攻擊者最常採用的技術包括：利用目標網站中的 Cross-Site Scripting 或 HTTP Response Splitting 弱點 [1]。透過誘使受害者向一個易受攻擊的應用程式提交惡意要求，讓應用程式將 JavaScript 或者其他程式碼反映到受害者的瀏覽器，這樣一來，攻擊者就可以建立 Cookie，使受害者重新使用受攻擊者控制的階段作業識別碼。

要特別注意的是，通常 Cookie 會與某個已知 URL 相關聯的上層網域繫結在一起。如果多個應用程式位於同一個上層網域 (例如 bank.example.com 和 recipes.example.com)，其中一個應用程式存在弱點，那麼攻擊者便可以透過此弱點設定一個 Cookie，並在其中包含已修改的階段作業識別碼，且該階段作業識別碼可以在 example.com [2] 網域上的所有應用程式中交互使用。

其他攻擊方向還包括 DNS Poisoning 和其他以網路為基礎的攻擊，攻擊者會透過重新指向對有效網站的要求，誘使攻擊者存取惡意網站。一般來說，以網路為基礎的攻擊包括：實際出現在受害者的網路上，或是控制網路上已受攻擊的機器。雖然透過遠端方式發動攻擊比較困難，但是這類攻擊不容忽視。安全性較差的階段作業管理機制 (例如在 Apache Tomcat 中的預設實作)，可以將通常儲存在 Cookie 中的階段作業識別碼也指定給 URL。這可讓攻擊者只要透過電子郵件發送惡意 URL，就可以誘使受害者使用修改過的階段作業識別碼。