CSRF和X-CSRF-Token之间的区别 [英] Difference between CSRF and X-CSRF-Token

问题描述

标题中使用 X-CSRF-Token 或隐藏字段中的令牌有什么区别？

What is the difference between use X-CSRF-Token in header or token in hidden field ?

我认为 X-CSRF-Token 是什么时候？我正在使用javascript / ajax，但不确定

I think that X-CSRF-Token is when i'm using javascript/ajax but im not sure

推荐答案

CSRF保护有多种方法。

CSRF protection comes in a number of methods.

传统方式（同步器令牌模式）通常涉及为每个请求设置唯一的有效Token值，然后在随后发送请求时验证该唯一值。通常通过设置隐藏的表单字段来完成。令牌值通常是短暂的，并且与该会话相关联，因此，如果黑客试图重用他们先前在页面上看到的值，或者试图猜测该值，它们很可能会失败。因此，只有来自您的应用程序的请求才能正常工作，来自您的应用程序/域之外的伪造请求（也称为跨站点请求伪造）将失败。

The traditional way (the "Synchronizer token" pattern) usually involves setting a unique valid Token value for each request and then verifying that unique value when the request is subsequently sent in. It is usually done by setting a hidden form field. The token value is usually short lived and associated to that session, so if a hacker tries to reuse a value they saw previously on the page, or tries to guess the value they will likely fail. So only requests from your application will work and forged requests from outside your application/domain (aka cross site request forgery) will fail.

缺点是它要求您应用程序在所有HTML表单上设置此隐藏令牌。这些页面现在必须由应用程序动态生成，而以前可能是静态HTML。它还可能破坏后退按钮（因为您需要刷新表单以重新生成另一个唯一的CSRF值）。现在，您还需要在服务器端跟踪有效令牌，并检查所有使用有效令牌的请求。

The downside of that is it requires your application to set this hidden token on all HTML forms. These pages now have to be dynamically generated by an application, when perhaps previously they were static HTML. It can also break the back button (as you need to refresh the form to regenerate another unique CSRF value). You also now need to keep track of valid tokens on the server side and check any requests use a valid token. This can take quite a bit of extra effort to implement and maintain going forward.

另一种方法（称为 Cookie-to-header令牌模式）是为每个会话设置一次Cookie，并让JavaScript读取该Cookie和设置自定义HTTP标头（通常称为 X-CSRF-TOKEN 或 X-XSRF-TOKEN 或仅 XSRF-TOKEN ）。任何请求都会发送标头（由Javascript设置）和cookie（由浏览器作为标准HTTP标头设置），然后服务器可以检查 X-CSRF-TOKEN 标头与cookie标头中的值匹配。这样的想法是，只有在同一域上运行的JavaScript才可以访问cookie，因此来自另一个域的JavaScript不能将此标头设置为正确的值（假设页面不容易受到允许访问此cookie的XSS的攻击） 。即使是伪造的链接（例如在网络钓鱼电子邮件中）也不会起作用，因为即使它们似乎来自正确的域，也只会设置cookie，而不会设置 X-CSRF-TOKEN 标头。

An alternative approach (called the "Cookie-to-header token" pattern) is to set a Cookie once per session and the have JavaScript read that cookie and set a custom HTTP header (often called X-CSRF-TOKEN or X-XSRF-TOKEN or just XSRF-TOKEN) with that value. Any requests will send both the header (set by Javascript) and the cookie (set by the browser as a standard HTTP header) and then the server can check that value in the X-CSRF-TOKEN header matches the value in the cookie header. The idea being that only JavaScript run on the same domain would have access to the cookie, so JavaScript from another domain couldn't set this header to the right value (assuming the page is not vulnerable to XSS that would give access to this cookie). Even fake links (e.g. in a phishing email) would not work either, as even though they would appear to come from the right domain, only the cookie will be set but not X-CSRF-TOKEN header.

与Synchronizer令牌模式相比，它实现起来容易得多，因为您无需为每次调用每个表单设置令牌，而且检查也相对简单（只需检查Cookie是否与标题匹配），而不是跟踪CSRF令牌的有效性。您需要为每个会话将Cookie设置为随机值。如果某些前端框架看到Cookie，它们甚至会自动为您生成标头（例如例如，AngularJS这样做。

This can be MUCH easier to implement than the Synchronizer token pattern as you don't need to set the token for each call to each form, and the check is relatively simple too (just check the cookie matches the header) rather than tracking CSRF tokens validity. All you need is to set a cookie to a random value for each session. Some front end frameworks will even automatically generate the header for you if they see the cookie (e.g. AngularJS does this for example).

缺点是它需要JavaScript才能工作（但可能如果您的应用程序基本上在没有JavaScript的情况下也无法正常工作，则不会有问题），并且仅适用于JavaScript发出的请求（例如XHR请求）-常规HTML表单请求不会设置标头。在此上的一种变体（双重提交Cookie模式）将 X-CSRF-TOKEN 值可以在隐藏的表单字段中而不是在HTTP标头中解决，但是仍然可以使服务器端逻辑比传统的Synchronizer令牌模式更简单。但是应注意， OWASP指出了一些Double Submit方法的弱点，当攻击者能够设置cookie（通常比读取cookie容易时），因此建议在这种情况下验证CSRF令牌。

The downside is that it requires JavaScript to work (but that may not be an issue if your app basically doesn't work without JavaScript anyway) and also it will only work for requests the JavaScript makes (e.g. XHR requests) - regular HTML form requests would not set the header. A variation on this (the "Double Submit Cookie" pattern) puts the X-CSRF-TOKEN value in a hidden form field rather than in an HTTP Header to get around this but still keep the server side logic simpler than the traditional Synchronizer token pattern. It should be noted however that OWASP states some weaknesses with the Double Submit method, when the attacker is able to set the cookie (which is often easier than reading the cookie) so recommends validating the CSRF token in this case.

此外，Synchronizer令牌模式可以允许其他控件强制执行流程（例如，仅当应用程序认为您已发送有效请求以获取该表单时，才会设置隐藏字段CSRF令牌）。

Additionally the Synchronizer token pattern can allow extra controls to enforce flow (e.g. the hidden field CSRF token will only be set when the application thinks you have sent a valid request in to get that form).

哦，某些安全扫描会发现未使用 HTTP-only 标志设置cookie的事实，因此可以通过JavaScript读取-但这是故意的，因为它需要能够阅读！错误警报。您可能会想，只要您使用 X-CSRF-TOKEN 这样的通用名称，他们就不会标记此标记，但是经常看到它被标记。

Oh and some security scans will pick up the fact the cookie is not set with the HTTP-Only flag so can be read by JavaScript - but that's deliberate as it needs to be able to read by that! False alert. You'd think as long as you are using a common name like X-CSRF-TOKEN they would know not to flag this, but have seen it flagged often.

这篇关于CSRF和X-CSRF-Token之间的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！