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

AntiForgery.Validate Always Validates Even When no Match

我有一个 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。

干杯

这个我也看到了。 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 的实施进行更多研究,但从我现在看到的一点点(以及下面的链接)来看,这些值肯定会有所不同。

我查看的参考资料:

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

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

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