我读过的
我阅读了以下有关会话修复的资源，但我仍然难以理解此类漏洞的某些方面：
让我们假设会话 ID 是服务器生成的，并且它们是从 cookie 存储和访问的，而不是通过GET和POST请求传递的。上面链接 #1 中的 Rails 指南描述了这样的攻击（从源代码总结，强调我的）：
攻击者创建一个有效的会话 id：他们加载他们想要修复会话的 Web 应用程序的登录页面，并从响应中获取 cookie 中的会话 id（参见图像中的数字 1 和 2）。
他们可能会维持会话。过期会话，例如每 20 分钟一次，大大缩短了攻击的时间范围。因此，他们不时访问 Web 应用程序以保持会话处于活动状态。
现在攻击者将强制用户的浏览器使用这个会话 id（见图片中的数字 3）。由于您可能无法更改另一个域的 cookie（因为同源策略），攻击者必须从目标 Web 应用程序的域运行 JavaScript。
攻击者使用 JavaScript 代码将受害者引诱到受感染的页面。通过查看页面，受害者的浏览器会将会话 ID 更改为陷阱会话 ID。
由于未使用新的陷阱会话，Web 应用程序将要求用户进行身份验证。
从现在开始，受害者和攻击者将在同一个会话中共同使用 Web 应用程序：会话变得有效并且受害者没有注意到攻击。
我不明白的事
现在这是我不明白的部分。撇开这种攻击的有效对策是在受害者用户登录到合法站点时简单地向他们发出一个新的会话 ID，为什么合法服务器仍然要求受害者用户登录，即使他们已经有一个“有效”的会话 ID？
毕竟，攻击者已经预先维护了固定会话 ID 的有效性（正如上面引用的 Rails 安全指南中的步骤 #2 中所指出的），那么为什么服务器不接受会话 ID 并记录受害者用户作为攻击者进入网站？为什么再次需要登录凭据？
请注意，此问题并非特定于 Ruby on Rails。它适用于任何框架和语言的用户会话的任何实现。