当前位置：文江博客话题详情

为什么不使用会话 ID 作为 XSRF 令牌？

发布于 2024-11-28 01:00:13 字数 2193 浏览 0 评论 0原文

为什么 Play Framework 使用[会话 ID 的签名版本] 作为跨站请求伪造 (XSRF/CSRF) 预防令牌，而不是会话 ID 本身？

（对于 XSRF 预防令牌，我的意思是必须包含在表单提交中的神奇值，以便 Web 应用程序接受表单。）

如果有窃听者，他/她无论如何都会找到 XSRF 令牌和 SID cookie（？）。

如果存在 XSS 漏洞，那么恶意 JavaScript 代码就可以读取 XSRF 令牌和 SID cookie（？）。

但是：

给定 SID，攻击者无法构建有效的 XSRF 令牌，因为他/她没有在签署 SID 以获得 XSRF 令牌时使用的密钥。 -- 但攻击者怎么可能只掌握 SID，而不掌握 XSRF 令牌呢？是不是太牵强了？
如果 SID 在 HTTP Only cookie 中发送，那么即使攻击者找到了 XSRF 令牌，攻击者也不会拥有 SID，也许攻击者真的需要 SID？ ——这是牵强吗？

代码片段：

这里 Play 构造了它的 XSRF 令牌（getId 返回会话 ID）： (play/framework/src/play/mvc/Scope.java)

    public String getAuthenticityToken() {
        return Crypto.sign(getId());
    }

这里 Play 检查

是否具有有效的 XSRF 令牌： (play/framework/src/play/mvc/Controller.java)

protected static void checkAuthenticity() {
    if(Scope.Params.current().get("authenticityToken") == null ||
       !Scope.Params.current().get("authenticityToken").equals(
                       Scope.Session.current().getAuthenticityToken())) {
        forbidden("Bad authenticity token");
    }
}

更新：

Play 更改了生成 XSRF 令牌的方式，现在不再使用 SID，而是签名并使用随机值！（我刚刚将我的 Play Framework Git 存储库克隆从旧的 Play 版本 1.1 更新到新的 1.2。也许我应该在昨天完成此操作，嗯。）

    public String getAuthenticityToken() {
        if (!data.containsKey(AT_KEY)) {
            data.put(AT_KEY, Crypto.sign(UUID.randomUUID().toString()));
        }
        return data.get(AT_KEY);
    }

那么，他们为什么要进行此更改呢？

我找到了提交：
[#669] 再次修复并应用 Flash 和错误
d6e5dc50ea11fa7ef626cbdf01631595cbdda54c

来自问题 #669 :
仅在绝对必要时才创建会话
会话 cookie 是在每次资源请求时创建的。如果会话中确实有数据要存储，则 play 应该只创建会话 cookie。

因此，他们使用随机值，而不是 SID，因为 SID 可能尚未创建。这就是不使用 SID 的衍生品作为 XSRF 令牌的原因。但没有澄清他们过去在使用 SID 时为何对其进行签名/哈希处理。

原文

Why does Play Framework use [a signed version of the session id] as Cross Site Request Forgery (XSRF/CSRF) prevention token, rather than the session ID itself?

(With XSRF prevention token, I mean a magic value that must be included in a form submission, for the webapp to accept the form.)

If there's an eavesdropper s/he'll find both the XSRF token and the SID cookie anyway (?).

If there's an XSS exploit, then the malicious JavaScript code can read both the XSRF token and the SID cookie (?).

However:

An attacker cannot construct a valid XSRF token, given a SID, since s/he doesn't have the secret key used when signing the SID to obtain the XSRF token. -- But how could it happen that an attacker gets hold of only the SID, not the XSRF token? Is that far-fetched?
If the SID is sent in a HTTP Only cookie, then an attacker wouldn't have the SID even if s/he found the XSRF token, and perhaps the attacker really needs the SID? -- Is this far-fetched?

Code snippets:

Here Play constructs it's XSRF token (getId returns the session ID):
(play/framework/src/play/mvc/Scope.java)

    public String getAuthenticityToken() {
        return Crypto.sign(getId());
    }

Here Play checks that a <form> has a valid XSRF token:
(play/framework/src/play/mvc/Controller.java)

protected static void checkAuthenticity() {
    if(Scope.Params.current().get("authenticityToken") == null ||
       !Scope.Params.current().get("authenticityToken").equals(
                       Scope.Session.current().getAuthenticityToken())) {
        forbidden("Bad authenticity token");
    }
}

Update:

Play has changed the way it generates XSRF tokens, now the SID is no longer used, instead a random value is signed and used! (I just updated my Play Framework Git repo clone from old Play version 1.1 to new 1.2. Perhaps I should have done this ... yesterday, hmm.)

    public String getAuthenticityToken() {
        if (!data.containsKey(AT_KEY)) {
            data.put(AT_KEY, Crypto.sign(UUID.randomUUID().toString()));
        }
        return data.get(AT_KEY);
    }

Well, then why did they do this change?

I found the commit:
[#669] Fix again and apply for Flash and Errors as well
d6e5dc50ea11fa7ef626cbdf01631595cbdda54c

From issue #669:
create session only when absolute necessary
A session cookie is created on every request of a resource. play should only create a session cookie if there is really data to be stored in the session.

So they're using a random value, not the SID, because the SID might not yet have been created. Well that's a reason not to use a derivative of the SID as XSRF token. But doesn't clarify why they signed/hashed the SID, in the past, when they were using it.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

晨敛清荷 2024-12-05 01:00:13

首先要说的是，您可以重复使用会话 ID 作为 CSRF 令牌，因为它可以很好地保护您免受 CSRF 的侵害，并且不会自动创建任何严重的安全漏洞。然而，出于某种合理的原因，OWASP 曾经明确建议反对它。（他们现在根本没有解决这个问题。）

反对重新使用会话 ID 作为 CSRF 令牌的论点可以总结如下（要点以粗体显示，下面有理由）：

会话 ID 是攻击者获取的安全漏洞通常比攻击者获取的 CSRF 令牌更严重。
攻击者从拥有 CSRF 令牌（假设其他一些安全信息，如会话 ID，尚未被重新用作 CSRF 令牌）中获得的就是执行 CSRF 攻击的能力。这给他们带来了两个巨大的限制，而如果他们真正获得了会话 ID，则不会有这些限制：
- 他们仍然需要用相应的会话令牌引诱用户进入攻击页面（或让他们阅读攻击电子邮件，或在 iframe 中查看攻击广告等），以任何方式利用 CSRF 令牌。有了会话 ID，他们只需将其放入浏览器中，然后就可以像该用户一样使用该网站。
- 虽然他们可以使用用户的凭据发送请求，但同源策略仍然阻止他们查看对这些请求的响应。这可能（也可能不会，具体取决于您所保护的 API 的结构和攻击者的聪明才智）在实践中意味着，虽然攻击者可以代表用户执行操作，但他们不能获取用户有权查看的敏感信息。（您更关心哪一个取决于具体情况 - 人们假设攻击者更愿意拿走您银行帐户的内容，而不是仅仅知道有多少钱，但他们也宁愿知道您的病史而不是破坏它。）
攻击者可能比会话 ID 更容易获取 CSRF 令牌
- XSS 攻击可能允许攻击者获取 CSRF 令牌，因为通常的做法是将其烘焙到 DOM 中（例如，作为元素的值） >
  另一方面，会话 cookie 可以是保留即使面对使用 HttpOnly 标志的成功 XSS 攻击，也需要攻击者进行更多的前期工作才能有效利用 XSS 漏洞。
但是，如果您将会话 ID 重新用作 CSRF 令牌，则任何允许他们获取 CSRF 令牌的攻击也会自动为他们提供会话 ID。
因此你不应该重复使用CSRF令牌作为会话ID，因为它使会话 ID 更容易受到攻击。

老实说，我认为以上所有内容更多地是一种理论问题，而不是实际问题。论证的弱点是第 2 点；我能想到的唯一可用于获取 CSRF 令牌但不能用于获取会话 cookie 的实际漏洞仍然是非常严重的漏洞。如果您的网站上存在 XSS 漏洞，或者攻击者可以访问您该死的服务器日志，那么您很可能就彻底完蛋了。在我去过的大多数图书馆和网吧中，工作人员都不太懂安全，很容易在不被发现的情况下安装键盘记录器并获取密码 - 攻击者无需前往图书馆和网吧。等待人们使用机器，然后抓取浏览器缓存的内容。

然而，除非您的环境在某种程度上使得在随机会话 ID 旁边存储额外的 CSRF 随机令牌变得困难，否则为什么不这样做呢？

The first thing to say is that you can reuse the session ID as the CSRF token, insofar as it will protect you fine against CSRF and does not automatically create any serious security holes. However, for somewhat sound reasons, OWASP used to explicitly recommend against it. (They now don't address the question at all.)

The argument against reusing the session ID as the CSRF token can be summarized as follows (key points in bold, with justification beneath):

The session ID being acquired by an attacker is generally a more serious security breach than the CSRF token being acquired by an attacker.
All that an attacker gains from having the CSRF token (assuming that some other secure piece of information, like the session ID, hasn't been reused as the CSRF token) is the ability to perform CSRF attacks. This gives them two huge limitations that they wouldn't have if they actually acquired a session ID:
- They still need to lure the user with the corresponding session token to an attack page (or have them read an attack email, or view an attack ad in an iframe, etc.) to exploit the CSRF token in any way at all. With the session ID, they'd just need to put it in their browser and then use the website as if they were that user.
- While they can send requests using the user's credentials, the Same Origin Policy still prevents them from viewing the responses to those requests. This may (or may not, depending on the structure of the API you're protecting and the attacker's ingenuity) mean in practice that while the attacker can perform actions on the user's behalf, they cannot acquire sensitive information that the user is authorized to view. (Which of these you care more about depends upon the context - one assumes that an attacker would tend to prefer taking the contents of your bank account to merely knowing how much that is, but that they'd also rather know your medical history than vandalise it.)
The CSRF token is potentially easier for an attacker to acquire than the session ID
- XSS attacks are likely to permit an attacker to acquire the CSRF token, since it's common practice to bake it into the DOM (e.g. as the value of an <input> element in a <form>. Session cookies, on the other hand, can be kept secret even in the face of a successful XSS attack using the HttpOnly flag, demanding more up-front work from an attacker to usefully exploit an XSS vulnerability.
- If the CSRF token is being sent back to the server as a request parameter rather than a custom HTTP header (guaranteed to be the case when including it in ordinary HTML <form> submits), then web server access logs will generally log the CSRF token on GET requests (as it's part of the URL). Thus an attacker who manages to view the access log would be able to acquire many CSRF tokens.
- Pages or scripts that the CSRF token is baked into may be cached in the user's browser, permitting an attacker to retrieve them from the cache (conceivably relevant after the user has, for example, used a public machine in a library or internet cafe, and then either cleared their cookies but not their cache, or used a 'Log Out' button that removes their session cookie from the browser without invalidating it server-side).
But if you're reusing the session ID as the CSRF token, then any attack that permits them to acquire the CSRF token automatically gives them the session ID as well.
Therefore you should not reuse the CSRF token as the session ID, since it makes the session ID more vulnerable.

To be honest, I kind of regard everything above as more of a theoretical concern than a practical one. The weak point in the argument is point 2; the only realistic vulnerabilities I can think of that could be used for acquiring CSRF tokens but not for acquiring session cookies are still really serious vulnerabilities. If you have an XSS hole on your site, or an attacker has access to your freaking server logs, chances are you're totally fucked anyway. And in most libraries and internet cafes I've been to, the staff were not security-savvy and it'd be pretty easy to install a keylogger undetected and just harvest passwords - there'd be no need for an attacker to go to the effort of waiting for people to use the machine and then ripping the contents of their browser cache.

However, unless your circumstances somehow make it difficult to store an additional random token for CSRF alongside the random session ID, why not just do it anyway for whatever modest security benefit it gives you?

回复收藏 0 原文