Question

我有一个带嵌入式角度客户端的MVC网站，我最近实施了防伪XSRF令牌作为安全措施。

我在Startup.cs中设置如下：

services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

app.Use(next => context =>
        {
            if (string.Equals(context.Request.Path.Value, "/", StringComparison.OrdinalIgnoreCase) ||
                string.Equals(context.Request.Path.Value, "/index.html", StringComparison.OrdinalIgnoreCase))
            {
                // We can send the request token as a JavaScript-readable cookie, and Angular will use it by default.
                var tokens = antiforgery.GetAndStoreTokens(context);
                context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken,
                    new CookieOptions() { HttpOnly = false });
            }

            return next(context);
        });

我已经在我的角度前端实现了它，如此：

{ provide: XSRFStrategy, useFactory: xsrfFactory}

export function xsrfFactory(): CookieXSRFStrategy {
return new CookieXSRFStrategy('XSRF-TOKEN', 'X-XSRF-TOKEN');
}

保护我的控制器，如：

[Authorize] //Validation of AzureAD Bearer Token.
[ValidateAntiForgeryToken]
public class UserController : Controller

旨在通过对我的API的任何调用验证X-XSRF-TOKEN标头，这对原始会话中的所有调用都能成功运行。但是，我的应用程序使用Adal来记录用户，并且在成功登录重定向之后，此验证步骤失败，我从我的API收到400以用于任何后续调用。

原始的X-XSRF-TOKEN标头仍然会在登录后发送来自我的角客户端的所有传出请求，所以我怀疑它必须是我的服务器端不再有令牌进行验证，或者我的服务器生成了新的和我的客户没有检索它。但无论出于什么原因它都会崩溃，如果不创建一些自定义过滤器就很难调试，所以我可以看到它里面发生了什么。

有没有办法在客户端重定向后重置此令牌，以便我的服务器和客户端再次分享它的常识？或者我应该在我的Index.html中生成令牌吗？

修改

上面编辑的控制器装饰缺少[Authorize]属性。

因此，我的控制器受到验证AzureAD Bearer令牌以及Anti-Forgery验证的步骤的保护。奇怪的是，删除AzureAD验证作为测试并没有解决问题。

Adal登录后输出中显示API调用失败的错误：

提供的防伪令牌适用于与当前用户不同的基于声明的用户。

Answer 1

根据我的理解，您使用令牌保护控制器。对于此问题，您可以参考下面验证反XSRF令牌的进度（参考this link）：

要验证传入的反XSRF令牌，开发人员在其MVC操作或控制器上包含ValidateAntiForgeryToken属性，或者从她的Razor页面调用@ AntiForgery.Validate（）。运行时将执行以下步骤：


读取传入的会话令牌和字段令牌，并从每个令牌中提取反XSRF令牌。在生成例程中，每个步骤（2）的反XSRF令牌必须相同。

如果当前用户已通过身份验证，则会将其用户名与存储在字段令牌中的用户名进行比较。用户名必须匹配。

如果配置了IAntiForgeryAdditionalDataProvider，则运行时将调用其ValidateAdditionalData方法。该方法必须返回布尔值true。

由于您使用后端Web API开发SPA应用程序，因此在向Web API发出请求时，它将始终发出不带身份的反XSRF令牌。当您使用反XSRF和Azure AD令牌将请求发送到后端时，此时Web API已通过Azure AD令牌对请求进行身份验证。在检查反XSRF令牌以匹配身份信息时，它总是返回false。

在这种情况下，如果后端仅使用熊令牌身份验证并将令牌与会话存储一起存储，则无需启用XSRF预防，因为其他人无法窃取令牌并伪造请求。

如果您的后端还支持cookie身份验证或基本身份验证，NTLM等，您可以通过在Application_Start方法中添加以下内容来禁用身份检查：AntiForgeryConfig.SuppressIdentityHeuristicChecks = true。（请参阅this link）< / p>

关于XSRF / CSRF abouth oauth和web API的更多细节，您可以参考以下主题：

How does ValidateAntiForgeryToken fit with Web APIs that can be accessed via web or native app?

AntiForgeryToken does not work well with OAuth via WebAPI

Answer 2

尝试将[ValidateAntiForgeryToken]替换为[AutoValidateAntiforgeryToken]

https://github.com/aspnet/Antiforgery/blob/dev/src/Microsoft.AspNetCore.Antiforgery/Internal/DefaultAntiforgeryTokenGenerator.cs

带有Angular的MVC - 使用Adal

2 个答案: