分布式 SPA 应用程序中的防伪令牌答案

【问题标题】：Antiforgery token in a distributed SPA application分布式 SPA 应用程序中的防伪令牌
【发布时间】：2018-07-03 04:13:40
【问题描述】：

我正在开发一个分布式高可用性单页应用程序，该应用程序由 docker 节点集群提供服务。有时一个节点会死掉（出于完全正当的原因，所以这不是问题）。然后，所有客户端都会无缝地重新路由到其他节点之一。不幸的是，它们的所有 XSRF 令牌都无效，因为它们存储在客户端的内存中。

因此，问题是，我们如何在基于 *nix 的设置中分配当前 XSRF 令牌的存储？

【问题讨论】：

您想用 SPA 中的 XSRF 令牌做什么？！？？它被称为 SPA，单页应用程序。该页面仅包含 SPA 的引导程序，一旦加载，就没有新请求，只有 json 或 xml 对 rest api 的请求。对于这些，您不要使用 cookie，而应该使用 EACH 请求 发送令牌（当然是通过 SSL）。当你以这种方式实现 RESTful 服务时，没有什么可以伪造的。
使用短期和长期令牌（分别为访问令牌和刷新令牌），您可以缓解它。如果您出于某种原因必须使用 cookie，也可以通过 http-only cookie See Jeff's post on it 来防止 xss
@Tseng，你在哪里看到我的帖子中提到了 cookie？
根据您的要求进行简单假设。为什么还要 XSRF？针对WebAPI/Restful Api 的 XSRF 仅在您不为每个请求传递令牌时才有效，这意味着发送 cookie。 XSRF 适用于 MVC 风格。例如，如果您的网站上有一个“订单”，我复制了该 html 代码，将其放在我自己的网站上，但将表单“操作”到您的网站，然后引诱用户访问我的虚假页面，并填写隐藏的表单并在用户单击以将其重定向到您的网站并触发订单时发送。没有 XSRF 令牌，如果您已登录，就会成功
因为表单会将用户重定向到您的网站，并在他们登录时发送表单和cookie。因此您需要XSRF，它会在每个请求上发生变化，因此攻击者无法执行此操作。但是当你有一个 SPA 时，你通常会调用一个 Rest-service/rest api 并且不使用 cookie，所以上面的方法不起作用。所以问题是：为什么你认为你需要anti-XSRF-token来做SPA吗？

标签： c# asp.net-core csrf x-xsrf-token

【解决方案1】：

总结一下我的cmets：

XSRF/CSRF 仅在您使用 Cookie 进行身份验证时才有可能。它允许攻击者将用户引诱到一个虚假页面，该页面将一个（通常是隐藏的）表单重定向到您的网站，其中包含攻击者填充的数据或通过调用图像标签中的脚本（如果获取请求有副作用，应该避免），即

<image src="http://yourdomain.com/user/5/delete"/>

当您使用 SPA（单页应用程序，用 JavaScript 编写的应用程序，它们仅由初始请求加载并且所有其他调用都通过 Ajax/JavaScript 发生）时，您通常会使用访问令牌（不透明令牌或 jwt 令牌）进行身份验证。

在每个请求中发送令牌不会受到 XSRF 的攻击，除非您使用 cookie 身份验证。 ASP.NET Core 文档明确指出：

https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery

一些攻击针对响应 GET 请求的站点端点，在这种情况下，可以使用图像标记来执行操作（这种形式的攻击在允许图像但阻止 JavaScript 的论坛站点上很常见）。使用 GET 请求更改状态的应用程序容易受到恶意攻击。

CSRF 攻击可能会针对使用 cookie 进行身份验证的网站，因为浏览器会将所有相关 cookie 发送到目标网站。但是，CSRF 攻击不仅限于利用 cookie。例如，Basic 和 Digest 身份验证也容易受到攻击。用户使用 Basic 或 Digest 身份验证登录后，浏览器会自动发送凭据，直到会话结束。

【讨论】：

介意评论否决票吗？ XSRF 仅在使用表单或可变获取请求时才需要考虑。 SPA 不需要它，除非它们或后台 api 的实现非常错误。 OP 需要正确理解 XSRF，而不是寻找错误问题/方法的解决方案
您也可以在 httponly cookie 中发送令牌。实际上，与通过将身份验证令牌放在内存/本地存储中来修复您暴露的潜在 xss 漏洞相比，使用另一个令牌缓解 CSRF 是微不足道的。 /httponly=false .
@SomeRandomName：总是取决于。通常在 WebApi 风格的应用程序上使用 cookie 是一种不好的做法，因为 XSRF 有点麻烦，而且通常 XSRF 比 XSS 更容易被利用。在 ajax 请求中处理 XSRF 令牌也可能有点麻烦，因为您需要在执行某些操作（例如更改人员地址）之前请求令牌并将该令牌与进行更改的请求一起传递。在作为加载表单的一部分完成的 ASP.NET Core MVC 中，在 SPA 应用程序中，您不会每次都加载表单（即第一次创建用户时）