我们正在使用 ASP.NET Core 构建 3 个不同的应用程序 MVC 应用程序、API、SPA（不是 Angular）。此应用程序中的所有操作仅适用于授权用户。这就是我们使用 IdentityServer 保护它们的原因。
我们使用 cookie 来存储不记名令牌的值。我知道 cookie 的值会自动发送到服务器。但是因为它应该作为授权标头添加，所以浏览器不会自动完成。
这是否会降低 CSRF 攻击的可能性？还是 CSRF 仍然可以使用不记名令牌，我们是否需要添加 CSRF 令牌？
【问题讨论】：
标签： asp.net-mvc asp.net-core openid-connect csrf-protection
是的，您仍然需要 CSRF 令牌。
如果您的 SPA 或 MVC 应用程序将根据用户的 GET 或 POST 操作向您的 API 发送请求，您仍然需要 CSRF 令牌。
假设有人欺骗您的用户点击触发您的 SPA 中的某个操作的链接，或者该链接会发布到您的 MVC 应用程序，该应用程序将很高兴地遵守并发送存储在 cookie 中的不记名令牌作为请求标头，就像何时用户点击了应用程序本身的链接。
这就是 CSRF 的重点，攻击者制作一个请求，就好像用户在您的 Web 应用程序中调用了一个操作一样。
【讨论】：
如果我理解正确，MVC 和 SPA 都使用 Identity Server 对用户进行身份验证，并将令牌存储在主要的 cookie 中以访问 API。
这里一般有两种情况：
您的 cookie 是 HTTP only（无法在前端访问）。然后您将 cookie 发送到 MVC 和 SPA 服务器端，这些服务器端提取 cookie 并将请求进一步发送到 API。在这种情况下，您像往常一样容易受到 CSRF 的攻击，因为您确实使用 cookie 进行了有效的身份验证，并且随后的令牌提取和针对 API 的不记名身份验证仅基于自动 cookie 身份验证的结果发生。
可在前端访问 Cookie。在这种情况下，您可以使用 Javascript 读取它们并将承载身份验证的请求发送到 MVC 和 SPA 服务器端（进一步传递给 API）或直接发送到 API，从而使所有后端忽略 cookie 内容，因为它们可能会受到损害。 在这种情况下，您不会受到 CSRF 的攻击（正如您指出的，必须明确构造承载身份验证标头）。但是，您很容易受到 XSS (cross site scripting) 的攻击：任何使用数据验证/清理中的安全漏洞或简单的第三方依赖注入到您的页面的代码都可以读取 cookie 并将它们重新发送到任何服务器。这种情况与使用本地/会话存储非常相似，因此任何描述其漏洞的文章也适用于您的场景（例如 here）。
所以你必须选择 CSRF 或 XSS 作为主要攻击。
使用防伪令牌可以完全防止 CSRF，但如果你不这样做，攻击很容易组织。
XSS 在理论上很难在现代开发中完全防止，因为您使用了大量的 3rd 方库（另一个 XSS 攻击向量 - 输入卫生问题通常不是问题，因为大多数 MVC 框架都是为了你默认like ASP NET Core）。但是，您有很大的机会避免它，这使得此选项在许多情况下成为合理的选择e.g. Auth0 recommends it。
【讨论】：