ruby-on-rails - Rails4 安全 : Session fixation possible at all using encrypted cookies?

Question

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

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

2) ...保持 session 活跃

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

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

是 secu 指南不是最新的还是我漏掉了一点？如果是后者那么...

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

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

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

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

感谢您的任何建议!

Answer 1

与其说是 cookie 加密(或签名)。如果没有签名和/或加密，攻击者就不需要求助于将 session 数据存储在 cookie 中的站点的 session 固定；他们可以制作自己的 cookie。

假设攻击者有办法将 cookie 设置 JavaScript 注入(inject)受害者将访问的页面，即 an XSS vulnerability .攻击的结果如下:

1. 攻击者访问站点并获取 session cookie。

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

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

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

CookieStore，Rails 默认 session 存储

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

其他 session 存储策略

这里是这种攻击更可行的地方。其他 session 存储仍然使用 cookie 来保存 session_id，但它们将 session 数据 存储在别处 — 在 cache 中。 , 在 database , 在 memcached等。在这种情况下，当攻击者在受害者通过身份验证后访问站点时，攻击者的 cookie(具有相同的 session_id)将导致 session 被加载。

仅HTTP

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

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

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