会话固定

Question

我是 Web 开发的新手，并试图解决安全问题。我在http://guides.rubyonrails.org/security.html 上浏览了这篇文章，这些是作者提到的攻击者如何修复会话的一些步骤。

1. 攻击者创建了一个有效的会话 ID：他将 Web 应用程序的登录页面加载到他想要修复会话的位置，并从响应中获取 cookie 中的会话 ID（参见图像中的数字 1 和 2）。
2. 他可能会维持会话。过期会话，例如每 20 分钟一次，大大缩短了攻击的时间范围。因此，他会不时访问 Web 应用程序以保持会话处于活动状态。
3. 现在，攻击者将强制用户的浏览器使用此会话 ID（请参见图中的数字 3）。由于您可能无法更改另一个域的 cookie（因为同源策略），攻击者必须从目标 Web 应用程序的域运行 JavaScript。通过 XSS 将 JavaScript 代码注入应用程序即可完成这种攻击。这是一个示例：
4. 攻击者使用 JavaScript 代码将受害者引诱到受感染的页面。通过查看页面，受害者的浏览器会将会话 ID 更改为陷阱会话 ID。
5. 由于未使用新的陷阱会话，Web 应用程序将要求用户进行身份验证。
6. 从现在开始，受害者和攻击者将通过同一个会话共同使用 Web 应用程序：会话变得有效，而受害者没有注意到攻击。

我不明白几点。

1. 既然会话是通过发送的，为什么在第 5 步让用户登录？
2. 我在 wiki 上看到了可能的解决方案，例如用户属性检查等。为什么我们不能在步骤5中输入用户名和密码时为登录的用户重置会话？

Answer 1

1) 攻击者在步骤 1 和 2 中收到一个尚未登录的会话。这是陷阱会话。在第 5 步，受害者登录时认为会话 id 是新的（并且是“秘密的”）。在受害者登录的那一刻，攻击者能够重新使用“秘密”会话 id 并有效地登录。

所以回答你的问题：让受害者登录是因为陷阱会话尚未登录，以欺骗受害者使用此会话 ID 登录。

2) 在解释了会话固定的步骤之后，第一个对策（第 2.8 节）是在登录后创建一个新会话并放弃旧会话。正是您的想法！