Session Fixation

在未释放当前会话标识符的情况下验证用户会给攻击者窃取验证会话的机会。

Session Fixation 漏洞会在以下情况中出现：

1.当 Web 应用程序验证某一用户时，没有首先释放当前会话，而是继续使用已经与该用户关联的会话。
2.攻击者能够夺取已知的用户会话标识符，因此，一旦该用户进行验证，攻击者便可以访问经过验证的会话。

在通常情况下，攻击者会利用 Session Fixation 漏洞在 Web 应用程序中创建一个新会话，并且记录与之关联的会话标识符。然后，攻击者会设法使受害者在服务器中的验证失败，从而通过当前会话来访问用户帐号。

Spring Security 等部分框架会在创建新会话时自动释放当前会话。若不采取此行为，应用程序将易遭受此类攻击。

示例 1：以下示例显示受 Spring Security 保护的应用程序的代码段，该应用程序中的会话固定保护已禁用。

	<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，就可以诱使受害者使用已被修改的会话标识符。