为什么将 CSRF 预防令牌放在 cookie 中很常见？

一个很好的理由（您已经谈到）是，一旦收到 CSRF cookie，它就可以在客户端脚本中的整个应用程序中使用，用于常规表单和 AJAX POST。这在 JavaScript 繁重的应用程序中是有意义的，例如 AngularJS 使用的应用程序（使用 AngularJS 并不要求应用程序是单页应用程序，因此当状态需要在 CSRF 值的不同页面请求之间流动时，它会很有用通常不能在浏览器中持续存在）。

考虑典型应用程序中的以下场景和流程，了解您描述的每种方法的一些优缺点。这些基于 Synchronizer Token Pattern。

请求正文方法

用户成功登录。服务器发出 auth cookie。用户单击以导航到表单。如果尚未为此会话生成，服务器会生成 CSRF 令牌，将其存储在用户会话中并将其输出到隐藏字段。用户提交表单。服务器检查隐藏字段是否匹配会话存储的令牌。

优点：

实施简单。

与 AJAX 一起工作。

适用于表格。

Cookie 实际上只能是 HTTP。

缺点：

所有表单都必须以 HTML 格式输出隐藏字段。

任何 AJAX POST 还必须包含该值。

页面必须提前知道它需要 CSRF 令牌，以便它可以将其包含在页面内容中，因此所有页面都必须在某处包含令牌值，这可能会使大型站点的实施变得耗时。

自定义 HTTP 标头（下游）

用户成功登录。服务器发出 auth cookie。用户单击以导航到表单。页面在浏览器中加载，然后发出 AJAX 请求以检索 CSRF 令牌。服务器生成 CSRF 令牌（如果尚未为会话生成），将其存储在用户会话中并将其输出到标头。用户提交表单（令牌通过隐藏字段发送）。服务器检查隐藏字段是否匹配会话存储的令牌。

优点：

与 AJAX 一起工作。

Cookie 只能是 HTTP。

缺点：

如果没有 AJAX 请求来获取标头值，则无法工作。

所有表单都必须动态地将值添加到其 HTML 中。

任何 AJAX POST 还必须包含该值。

页面必须首先发出 AJAX 请求才能获取 CSRF 令牌，因此每次都意味着额外的往返。

还不如简单地将令牌输出到可以保存额外请求的页面。

自定义 HTTP 标头（上游）

用户成功登录。服务器发出 auth cookie。用户单击以导航到表单。如果尚未为此会话生成，服务器会生成 CSRF 令牌，将其存储在用户会话中并将其输出到页面内容中的某处。用户通过 AJAX 提交表单（令牌通过标头发送）。服务器检查自定义标头与会话存储的令牌匹配。

优点：

与 AJAX 一起工作。

Cookie 只能是 HTTP。

缺点：

不适用于表格。

所有 AJAX POST 都必须包含标头。

自定义 HTTP 标头（上游和下游）

用户成功登录。服务器发出 auth cookie。用户单击以导航到表单。页面在浏览器中加载，然后发出 AJAX 请求以检索 CSRF 令牌。服务器生成 CSRF 令牌（如果尚未为会话生成），将其存储在用户会话中并将其输出到标头。用户通过 AJAX 提交表单（令牌通过标头发送）。服务器检查自定义标头与会话存储的令牌匹配。

优点：

与 AJAX 一起工作。

Cookie 只能是 HTTP。

缺点：

不适用于表格。

所有 AJAX POST 还必须包含该值。

页面必须首先发出 AJAX 请求才能获取 CRSF 令牌，因此每次都意味着额外的往返。

设置Cookie

用户成功登录。服务器发出 auth cookie。用户单击以导航到表单。服务器生成 CSRF 令牌，将其存储在用户会话中并将其输出到 cookie。用户通过 AJAX 或 HTML 表单提交表单。服务器检查自定义标头（或隐藏的表单字段）是否与会话存储的令牌匹配。 Cookie 可在浏览器中用于额外的 AJAX 和表单请求，而无需额外请求服务器来检索 CSRF 令牌。

优点：

实施简单。

与 AJAX 一起工作。

适用于表格。

不一定需要 AJAX 请求来获取 cookie 值。任何 HTTP 请求都可以检索它，并且可以通过 JavaScript 将其附加到所有表单/AJAX 请求中。

检索到 CSRF 令牌后，由于它存储在 cookie 中，因此无需额外请求即可重用该值。

缺点：

所有表单都必须动态地将值添加到其 HTML 中。

任何 AJAX POST 还必须包含该值。

cookie 将针对每个请求提交（即所有 GET 的图像、CSS、JS 等，不涉及 CSRF 过程）增加请求大小。

Cookie 不能是 HTTP Only。

因此 cookie 方法是相当动态的，提供了一种简单的方法来检索 cookie 值（任何 HTTP 请求）并使用它（JS 可以自动将值添加到任何表单中，它可以在 AJAX 请求中用作标头或用作形式值）。一旦收到会话的 CSRF 令牌，就无需重新生成它，因为使用 CSRF 漏洞的攻击者没有检索此令牌的方法。如果恶意用户尝试通过上述任何方法读取用户的 CSRF 令牌，则 Same Origin Policy 将阻止这种情况。如果恶意用户尝试检索 CSRF 令牌服务器端（例如通过 curl），则此令牌将不会与同一用户帐户相关联，因为请求中将丢失受害者的身份验证会话 cookie（这将是攻击者的 -因此它不会将服务器端与受害者的会话相关联）。

除了 Synchronizer Token Pattern 还有 Double Submit Cookie CSRF 预防方法，它当然使用 cookie 来存储一种 CSRF 令牌。这更容易实现，因为它不需要 CSRF 令牌的任何服务器端状态。使用此方法时，CSRF 令牌实际上可能是标准身份验证 cookie，并且该值与请求一样通过 cookie 提交，但该值也在隐藏字段或标头中重复，攻击者无法将其复制为他们首先无法读取该值。但是，建议选择另一个 cookie，而不是身份验证 cookie，以便可以通过标记为 HttpOnly 来保护身份验证 cookie。因此，这是您使用基于 cookie 的方法发现 CSRF 预防的另一个常见原因。

---

使用 cookie 向客户端提供 CSRF 令牌不允许成功攻击，因为攻击者无法读取 cookie 的值，因此无法将其放置在服务器端 CSRF 验证要求的位置。

攻击者将能够使用请求标头中的身份验证令牌 cookie 和 CSRF cookie 向服务器发起请求。但是服务器并没有在请求标头中将 CSRF 令牌作为 cookie 来查找，而是在请求的有效负载中查找。即使攻击者知道将 CSRF 令牌放在有效负载中的哪个位置，他们也必须读取其值才能将其放在那里。但是浏览器的跨域策略会阻止从目标网站读取任何 cookie 值。

相同的逻辑不适用于身份验证令牌 cookie，因为服务器期望它在请求标头中，并且攻击者不需要做任何特殊的事情就可以将它放在那里。

---

我对答案的最佳猜测：考虑如何将 CSRF 令牌从服务器下载到浏览器的这 3 个选项。

在请求正文中（不是 HTTP 标头）。在自定义 HTTP 标头中，而不是 Set-Cookie。作为 cookie，在 Set-Cookie 标头中。

我认为第一个请求正文（由 the Express tutorial I linked in the question 演示）不能在各种情况下移植。不是每个人都在动态生成每个 HTTP 响应；您最终需要将令牌放入生成的响应中的位置可能会有很大差异（在隐藏的表单输入中；在 JS 代码片段或其他 JS 代码可访问的变量中；甚至可能在 URL 中，尽管这通常看起来是一个糟糕的地方放置 CSRF 令牌）。因此，虽然可以进行一些定制，但#1 是一个很难做到一刀切的方法的地方。

第二个，自定义标头，很有吸引力，但实际上不起作用，因为 while JS can get the headers for an XHR it invoked, it can't get the headers for the page it loaded from。

剩下的第三个，由 Set-Cookie 标头携带的 cookie，作为一种在所有情况下都易于使用的方法（任何人的服务器都可以设置每个请求的 cookie 标头，无论哪种类型的数据在请求正文中）。因此，尽管有缺点，但它是框架广泛实施的最简单方法。

---

除了会话 cookie（这是一种标准），我不想使用额外的 cookie。

在构建具有许多 AJAX 请求的单页 Web 应用程序 (SPA) 时，我找到了一个适合我的解决方案。注意：我使用的是服务器端 Java 和客户端 JQuery，但没有什么神奇的东西，所以我认为这个原理可以在所有流行的编程语言中实现。

我没有额外 cookie 的解决方案很简单：

客户端

将成功登录后服务器返回的 CSRF 令牌存储在全局变量中（如果您想使用 Web 存储而不是全局，那当然可以）。指示 JQuery 在每个 AJAX 调用中提供 X-CSRF-TOKEN 标头。

主“索引”页面包含以下 JavaScript 片段：

// Intialize global variable CSRF_TOKEN to empty sting. 
// This variable is set after a succesful login
window.CSRF_TOKEN = '';

// the supplied callback to .ajaxSend() is called before an Ajax request is sent
$( document ).ajaxSend( function( event, jqXHR ) {
    jqXHR.setRequestHeader('X-CSRF-TOKEN', window.CSRF_TOKEN);
}); 

服务器端

成功登录后，创建一个随机（且足够长）的 CSRF 令牌，将其存储在服务器端会话中并将其返回给客户端。通过将 X-CSRF-TOKEN 标头值与会话中存储的值进行比较来过滤某些（敏感）传入请求：这些应该匹配。

敏感的 AJAX 调用（POST 表单数据和 GET JSON 数据）以及捕获它们的服务器端过滤器位于 /dataservice/* 路径下。登录请求不得命中过滤器，因此它们位于另一条路径上。对 HTML、CSS、JS 和图像资源的请求也不在 /dataservice/* 路径上，因此未被过滤。这些不包含任何秘密，也不会造成伤害，所以这很好。

@WebFilter(urlPatterns = {"/dataservice/*"})
...
String sessionCSRFToken = req.getSession().getAttribute("CSRFToken") != null ? (String) req.getSession().getAttribute("CSRFToken") : null;
if (sessionCSRFToken == null || req.getHeader("X-CSRF-TOKEN") == null || !req.getHeader("X-CSRF-TOKEN").equals(sessionCSRFToken)) {
    resp.sendError(401);
} else
    chain.doFilter(request, response);
}   

---