Rails4 安全性：使用加密 cookie 完全可以固定会话？

Question

在研究了 rails 指南和其他一些资源之后，我想知道如何实际发生对用户会话的会话固定攻击。至少我怀疑它是否像指南中的简单 as depicted here 那样工作，攻击者...

1) ...通过登录创建一个有效的会话

2) ...使会话保持活动状态

3) ...然后强制用户使用他的会话ID，例如通过使用一些 XSS 漏洞

一切都好，但是......攻击者如何能够收集他自己的会话 ID 的值？默认情况下，cookie 在 Rails4+ 中是加密的。那么假设 我没有 可以访问secret_key_base 或用于生成加密和签名密钥的任何内容，作为攻击者该怎么办？据我了解，我无法在不使其失效的情况下篡改 cookie（签名错误），因此以某种方式将自行创建的 cookie 传递给可能的受害者也不是一种选择。

secu 指南是不是最新的，还是我在这里遗漏了一点？如果是后者的话……

a) [作为攻击者] 我如何读取加密的 cookie 信息

b) 一个漏洞如何才能让我 [攻击者] 将该会话 ID 注入另一个客户端上同样加密的 cookie 中？那会是XSS攻击吗？该指南指出，如果攻击者使用类似

的代码

<script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>

他也许能够修复那个会话。但同样，为什么 rails 会向客户端显示它是普通会话，使其可以通过客户端处理的 javascript 访问？它没有，这就是为什么我所有的 cookie 值都是简单的胡言乱语，无法通过 Javascript 访问（可以通过控制台测试），对吧？

感谢您的建议！

Answer 1

这与 cookie 加密（或签名）无关。在没有签名和/或加密的情况下，攻击者不需要借助将会话数据存储在 cookie 中的站点进行会话固定；他们可以自己制作饼干。

假设攻击者有办法将设置 cookie 的 JavaScript 注入受害者将访问的页面，即an XSS vulnerability。以下是攻击的结果：

1. 攻击者访问该站点并获取会话 cookie。

2. 攻击者制作恶意 JavaScript，利用 XSS 漏洞，并等待用户访问（或引诱用户访问）包含恶意 JavaScript 负载的页面。

   <script>document.cookie="_appname_session=(...attacker's session cookie...)";</script>
   

3. 受害者出现并使用恶意 JavaScript 访问页面，使用来自攻击者的 cookie 设置或覆盖其会话 cookie。
4. 如果他们已登录，网站将不再将他们识别为经过身份验证的用户，并且可能会将他们重定向到登录。
5. 如果他们没有登录，他们将被重定向到登录页面。
6. 他们使用自己的用户名和密码进行身份验证。
7. 此时，受害者和攻击者都有一个 cookie，其中包含属于已通过身份验证的用户的 session_id。

CookieStore，Rails 默认会话存储

通常您会在会话中设置一些值来指示用户已通过身份验证。即使像session[:logged_in] = true这么简单，它也会改变cookie的值，攻击者将无法访问该站点，即使session_id相同，因为攻击者的cookie不包含额外的表示经过身份验证的会话的数据。

其他会话存储策略

这里是这种攻击更可行的地方。其他会话存储仍然使用 cookie 来保存 session_id，但它们将会话 data 存储在其他地方——cache、database、memcached 等。在这种情况下，当攻击者在受害者通过身份验证后访问该站点，攻击者的 cookie（具有相同的 session_id）将导致会话被加载。

HttpOnly

然而，这次攻击还有另一个主要障碍——HttpOnly cookies。

Set-Cookie: _appname_session=v%2Ba...; path=/; HttpOnly

当 cookie 被指定为 HttpOnly 时，就像 Rack/Rails 会话 cookie 一样，浏览器不会通过 document.cookies 公开它。 JavaScript 既不能读取也不能覆盖它。我尝试通过 document.cookie 设置一个已知的会话 cookie，但除非我先清除现有的 cookie，否则这是不可能的。这意味着攻击者需要一个还没有会话 cookie 的用户在登录之前访问带有 XSS 漏洞的页面（这需要在没有会话 cookie 的页面上）。

Answer 2

据我了解，如果会话详细信息存储在 cookie 本身中，会话固定将不起作用。老式的会话方式，会话数据将保存在某种数据库中。保存在 cookie 中的会话 ID 将指向保存会话数据的记录或文件。这意味着随着会话的改变，cookie 根本不会改变。如果黑客拥有与用户相同的 cookie，则当用户登录时，他们可能会劫持登录，因为他们的 cookie 将指向现在附加了 user_id（以及可能的其他数据）的会话。在新系统下，对会话的任何更改也会更改 cookie，因此黑客的旧 cookie 将只有一个空会话。

话虽如此，最好将reset_session 添加到登录、注销和注册端点（如果您使用类似设计的东西，这可能会为您完成），因为如果您或某些未来的开发人员将会话存储更改为如果有数据库支持，您最终可能会自责。安全指南也不知道您使用的是哪种类型的会话存储，因此他们必须包含该建议。