AntiForgery.Validate 即使没有匹配也始终验证

Question

我有一个 class，用于执行有效载荷为 Json 的防伪令牌验证。 class 看起来像这样（来自 Phil Haacked）：

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
public class ValidateJsonAntiForgeryTokenAttribute : FilterAttribute, IAuthorizationFilter
{
    public void OnAuthorization(AuthorizationContext filterContext)
    {
        if (ReferenceEquals(filterContext, null)) throw new ArgumentNullException("filterContext");

        var request = filterContext.HttpContext.Request;

        //  Only validate POSTs
        if (request.HttpMethod == WebRequestMethods.Http.Post)
        {
            //  Ajax POSTs and normal form posts have to be treated differently when it comes
            //  to validating the AntiForgeryToken
            if (request.IsAjaxRequest())
            {
                var antiForgeryCookie = request.Cookies[AntiForgeryConfig.CookieName];

                var cookieValue = ReferenceEquals(antiForgeryCookie, null) ? null : antiForgeryCookie.Value;

                AntiForgery.Validate(cookieValue, request.Headers[AntiForgeryConfig.CookieName]);
            }
            else
            {
                new ValidateAntiForgeryTokenAttribute().OnAuthorization(filterContext);
            }
        }

    }
}

这是我使用它的第一个 Angular 项目，它没有像我期望的那样抛出异常。例如，header 中的值与 cookie 中的值不同，并且对 AntiForgery.Validate 的调用无一例外地进行。

anti-forgery 标记在 shell 视图（即 Index.cshtml）中呈现，并添加到 Angular 中的 header模块运行功能：

// Handle routing errors and success events
theApp.run(['$http', '$route', '$rootScope', '$q', 'routeOverlord',
    function ($http, $route, $rootScope, $q, routeOverlord) {
        // Include $route to kick start the router.
        routeOverlord.setRoutingHandlers();

        // Include AntiForgeryToken to prevent CSRF attacks
        $http.defaults.headers.common['__RequestVerificationToken'] = angular.element('input[name="__RequestVerificationToken"]').val();
    }]);

这是众所周知的事情吗？很高兴提供 cookie 中不同字符串的 Fiddler 屏幕截图，如果需要，header。

干杯

Answer 1

这个我也看到了。 cookie 值和字段值不同，但 .Net 框架仍然允许它们通过。

这是因为 .Net Framework 的实现比简单的值匹配检查要复杂一些。

查看 Github 上的源代码后，发现令牌包含除 GUID 之外的其他信息（它们将其与当前用户绑定）。

我可以从 TokenValidator 中看到，cookie 值是表示 SessionToken 的令牌，其中字段值（您的 header 值）不应是 session 令牌。

// Do the tokens have the correct format?
if (!sessionToken.IsSessionToken || fieldToken.IsSessionToken)
{
    throw HttpAntiForgeryException.CreateTokensSwappedException(_config.CookieName, _config.FormFieldName);
}

但它们仍然用于验证操作确实来自授权用户，而不是来自恶意人员的预制攻击。

我个人需要对 Microsoft 的实施进行更多研究，但从我现在看到的一点点（以及下面的链接）来看，这些值肯定会有所不同。

我查看的参考资料：

Answer 2

cookie 令牌和表单令牌（在您的情况下 headers 中的那个）不应该是相同的（这样更容易伪造） .

cookie 标记包含随机 blob。表单令牌包含相同的 blob，以及一些身份数据（以及可选的一些附加数据）。

AntiForgery.Validate() 检查两个 blob 是否相同，以及表单令牌中的其他数据是否对应于身份数据和可选的附加数据。

AntiForgery.Validate 即使没有匹配也始终验证

AntiForgery.Validate Always Validates Even When no Match

asp.net

asp.net-mvc-5

antiforgerytoken