security - CSRF 和 X-CSRF-Token 的区别

Question

• 在 HTTP header 中使用 X-CSRF-Token 或 token 有什么区别 在隐藏字段中？
• 何时使用隐藏字段以及何时使用 header ，为什么？

我认为 X-CSRF-Token 是在我使用 JavaScript/AJAX 时，但我不确定。

Answer 1

CSRF 保护有多种方法。

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

缺点是它要求您的应用程序在所有 HTML 表单上设置此隐藏标记。这些页面现在必须由应用程序动态生成，而以前它们可能是静态 HTML。它还可以破坏后退按钮(因为您需要刷新表单以重新生成另一个唯一的 CSRF 值)。您现在还需要在服务器端跟踪有效 token 并检查所有请求是否使用有效 token 。这可能需要相当多的额外努力来实现和维护。

另一种方法(称为 the "Cookie-to-header token" pattern)是为每个 session 设置一次 Cookie，然后让 JavaScript 读取该 cookie 并设置自定义 HTTP header (通常称为 X-CSRF-TOKEN 或 X-XSRF-TOKEN 或只是 XSRF-TOKEN) 具有该值。任何请求都会发送 header (由 Javascript 设置)和 cookie(由浏览器设置为标准 HTTP header )，然后服务器可以检查 X-CSRF-TOKEN header 中的值是否匹配cookie header 中的值。这个想法是只有在同一域上运行的 JavaScript 才能访问 cookie，因此来自另一个域的 JavaScript 无法将此 header 设置为正确的值(假设该页面不易受到可以访问此 cookie 的 XSS 攻击) .即使是虚假链接(例如在网络钓鱼电子邮件中)也不会起作用，因为即使它们看起来来自正确的域，也只会设置 cookie 而不是 X-CSRF-TOKEN header 。

这比 Synchronizer token 模式更容易实现，因为您不需要为每个表单的每次调用设置 token ，而且检查也相对简单(只需检查 cookie 与 header 匹配)而不是跟踪 CSRF token 有效性。您所需要的只是为每个 session 设置一个 cookie 为一个随机值。如果某些前端框架看到 cookie(例如 AngularJS does this)，甚至会自动为您生成 header 。

缺点是它需要 JavaScript 才能工作(但如果您的应用程序基本上没有 JavaScript 就无法工作，这可能不是问题)，而且它只适用于 JavaScript 发出的请求(例如 XHR 请求)- 常规HTML 表单请求不会设置 header 。对此的一种变体("Double Submit Cookie" pattern)将 X-CSRF-TOKEN 值放在隐藏的表单字段中，而不是放在 HTTP header 中，以解决这个问题，但仍然保持服务器端逻辑比传统的同步器 token 模式。但是应该注意的是 OWASP states some weaknesses with the Double Submit method ，当攻击者能够设置 cookie(这通常比读取 cookie 更容易)时，建议在这种情况下验证 CSRF token 。

此外，Synchronizer token 模式可以允许额外的控制来强制执行流程(例如，仅当应用程序认为您已发送有效请求以获取该表单时，才会设置隐藏字段 CSRF token )。

哦，一些安全扫描会发现 cookie 没有设置 HTTP-Only 标志，因此可以被 JavaScript 读取 - 但这是故意的，因为它需要能够被读取那!错误警报。您可能会认为，只要您使用像 X-CSRF-TOKEN 这样的通用名称，他们就会知道不要标记它，但经常看到它被标记。