3

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

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 无法访问（可以通过控制台测试），对吧？

感谢您的任何建议！

4

2 回答 2

0

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

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

于 2021-12-07T16:59:02.660 回答
0

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

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

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

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

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

CookieStore，Rails 默认会话存储

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

其他会话存储策略

这是这种攻击更可行的地方。其他会话存储仍然使用 cookie 来保存 session_id，但它们将会话数据存储在其他地方——缓存中、数据库中、内存缓存中等。在这种情况下，当攻击者在受害者经过身份验证后访问该站点时，攻击者的cookie — 具有相同的 session_id — 将导致会话被加载。

HttpOnly

但是，这种攻击还有另一个主要障碍—— HttpOnly cookie。

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

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

于 2019-10-06T14:51:41.903 回答