如何在 MVC 或 Web Api ajax 调用中验证引荐来源网址

Question

我的 MVC 应用程序有常用的 ajax 方法（在 web api 和常规控制器中）。我想根据呼叫来自我的应用程序的哪个区域（视图）来授权这些呼叫。我面临的问题是如何验证 ajax 调用的来源。

我意识到这并不容易，因为 ajax 调用很容易被欺骗，但由于我可以完全控制视图的呈现方式（完整页面源代码），也许有一种方法可以嵌入防伪类型令牌，可以稍后被验证为 Url Referrer。

身份验证已经处理，我可以安全地验证调用的身份，唯一的问题是验证调用来自哪个 URL（MVC 路由）。更具体地说，防止用户能够欺骗 ajax 调用的来源。

我尝试创建一个自定义授权标头并在视图渲染和 ajax 调用之间传递它，这很有效，但仍然很容易被欺骗（因为用户可以从站点的另一部分嗅探标头并重新使用它们）。最后我不确定如何安全地验证标头没有被欺骗。唯一想到的是对令牌内的原始上下文的一些信息进行编码，并以某种方式针对传入调用上下文（在 ajax 调用中传递令牌的上下文）对其进行验证。

我看到 MVC 具有 AntiForgery 令牌功能，但我不确定这是否能解决我的问题。如果是这样，我想知道如何使用它来验证 /api/common/update 是从 /home/index 与 /user/setup 调用的（这两个调用都是有效的）。

再次，我想要一种方法来验证 ajax 调用来自哪个页面，并且用户身份不是问题。

更新

按照@Sarathy 的建议，我尝试实施防伪令牌。据我所知，这是通过在每个页面上添加一个带有令牌的隐藏字段并将其与 cookie 中设置的令牌进行比较来实现的。这是我执行令牌验证的自定义操作过滤器属性的实现：

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var req = filterContext.RequestContext.HttpContext.Request;
        var fToken = req.Headers["X-Request-Verification-Token"];
        var cookie = req.Cookies[AntiForgeryConfig.CookieName];
        var cToken = cookie != null
            ? cookie.Value
            : "null";

        log.Info("filter \ntoken:{0} \ncookie:{1}", fToken, cToken);
        AntiForgery.Validate(cToken, fToken);
        base.OnActionExecuting(filterContext);
    }

那么我的防伪附加数据提供者如下所示：

public class MyAntiForgeryProvider : IAntiForgeryAdditionalDataProvider
{
    public string GetAdditionalData(System.Web.HttpContextBase context)
    {
        var ad  = string.Format("{0}-{1}",context.Request.Url, new Random().Next(9999));
        log.Info("antiforgery AntiForgeryProvider.GetAdditionalData Request.AdditionalData: {0}", ad);
        log.Info("antiforgery AntiForgeryProvider.GetAdditionalData Request.UrlReferrer: {0}", context.Request.UrlReferrer);
        return ad;
    }

    public bool ValidateAdditionalData(System.Web.HttpContextBase context, string additionalData)
    {
        log.Info("antiforgery AntiForgeryProvider.ValidateAdditionalData Request.Url: {0}", context.Request.Url);
        log.Info("antiforgery AntiForgeryProvider.ValidateAdditionalData additionalData: {0}", additionalData);
        return true;
    }

这很有效，因为我可以看到在提供程序中登录的正确页面，并且防伪在没有令牌的情况下中断。

但是，除非我做错了什么，否则这似乎是微不足道的恶搞。例如 如果我去pageA并复制令牌表单pageB（只是表单令牌，甚至不是cookie令牌），这仍然成功，并且在我的日志中我看到pageB同时从pageA执行ajax方法

确认这很容易被欺骗。

我正在使用 csrf 生成这样的 ajax 令牌：

    public static string MyForgeryToken(this HtmlHelper htmlHelper)
    {
        var c = htmlHelper.ViewContext.RequestContext.HttpContext.Request.Cookies[AntiForgeryConfig.CookieName];
        string cookieToken, formToken;
        AntiForgery.GetTokens(c != null ? c.Value : null, out cookieToken, out formToken);
        return formToken;
    }

然后，我将表单令牌与每个 ajax 调用一起传回，并有一个自定义的 actionfilterattribute 与 cookie 令牌一起读取/验证它

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var req = filterContext.RequestContext.HttpContext.Request;
        var fToken = req.Headers[GlobalConstants.AntiForgeKey];
        var cookie = req.Cookies[AntiForgeryConfig.CookieName];
        var cToken = cookie != null
            ? cookie.Value
            : "null";


        log.Info("MyAntiForgeryAttribute.OnActionExecuting. \ntoken:{0} \ncookie:{1}", fToken, cToken);
        AntiForgery.Validate(cToken, fToken);

这一切都有效（更改有关令牌的任何内容都会引发正确的异常），然后在我的 IAntiForgeryAdditionalDataProvider 中，我可以看到它认为它正在处理的内容。

一旦我从另一个视图覆盖 csrf 令牌，它就会认为它就是那个视图。我什至不必篡改 UrlReferrer 来打破这个：/

如果我可以强制 cookie 在每次页面加载时都不同，这可能会起作用

Answer 1

我假设您可以为此使用 IAntiForgeryAdditionalDataProvider。

public class CustomDataProvider : IAntiForgeryAdditionalDataProvider
{
   public string GetAdditionalData(HttpContextBase context)
   {
     // Return the current request url or build a route or create a hash from a set of items from the current context.
     return context.Request.Url.ToString();
    }

    public bool ValidateAdditionalData(HttpContextBase context, string additionalData)
    {
       // Check whether the allowed list contains additional data or delegate the validation to a separate component.
       return false;
     }
}

在 App_Start 中注册提供程序，如下所示。

AntiForgeryConfig.AdditionalDataProvider = new CustomDataProvider();

https://msdn.microsoft.com/en-us/library/system.web.helpers.iantiforgeryadditionaldataprovider(v=vs.111).aspx

希望这对您的方案有所帮助。

Answer 2

您在问题中提到您正在寻找防伪令牌功能。

因此，我认为您要问的是反 CSRF 解决方案（CSRF=cross site request forgery）。

一种方法是在您的页面中呈现一个真正的随机数（一次性令牌），然后在每个请求中传递它，这可以通过添加键/值来完成与请求标头配对，然后在后端（即在您的控制器内部）进行检查。这是一种挑战-响应方法。

正如你所说，在服务器端代码中你可以使用

var fToken = req.Headers["X-Request-Verification-Token"];

从请求页面获取。

要从页面的每个客户端 AJAX 请求传递它，您可以使用

var tokenValue = '6427083747'; // replace this by rendered random token
$(document).ajaxSend(function (event, jqxhr, settings) {
        jqxhr.setRequestHeader('X-Request-Verification-Token', tokenValue);
});

或者您可以使用为每个请求设置它

var tokenValue = '2347893735'; // replace this by rendered random token
$.ajax({
    url: 'foo/bar',
    headers: { 'X-Request-Verification-Token': tokenValue }
});

注意tokenValue需要包含网页发送给客户端时网页服务器渲染的随机数。

我不会为此使用 cookie，因为 cookie 不能保护您免受 CSRF 的影响——您需要确保请求的页面与呈现的页面相同（因此由 Web 服务器创建） .位于同一浏览器窗口中不同选项卡上的页面也可以使用 cookie。

详情可在OWASP project 页面上的OWASP CSRF prevention cheat sheet 中找到。

Answer 3

我的快速临时解决方案是使用在每个页面加载时创建的自定义令牌（我在令牌缓存中跟踪的 guid），这些令牌在所有 ajax 调用中作为标头传递。此外，我创建了一个原始 url 哈希并将其组合到自定义身份验证令牌中。 然后在我的 ajax 方法中提取哈希并将其与 UrlReferrer 哈希进行比较，以确保它没有被篡改。 由于自定义令牌总是不同的，因此猜测发生了什么不太明显，因为令牌在每次页面加载时似乎都不同。然而，这并不安全，因为只要付出足够的努力，就可以发现 url 哈希。由于用户身份不是问题，因此暴露在一定程度上是有限的，因此最坏的情况是给定用户将获得对站点另一部分的写访问权限，但只能以他自己的身份访问。我的网站是内部的，我正在审核一举一动，因此任何发脾气的企图都会很快被抓住。

我同时使用 jQuery 和 Angular，因此在所有请求中附加标记，如下所示：

var __key = '@Html.GetHeaderKey()' //helper method to get key from http header
//jQuery
$.ajaxSetup({
    beforeSend: function (xhr, settings) {
    xhr.setRequestHeader('X-Nothing-To-See-Here', __key); // totally inconspicuous 
})

//angular
app.config(['$httpProvider', function ($httpProvider) {
  $httpProvider.defaults.headers.common['X-Nothing-To-See-Here'] = __key;
});

更新

这种方法的缺点是自定义令牌需要在网络场或应用重新启动时保留。基于@Sarathy 的想法，我试图通过利用 MVC 防伪框架来解决这个问题。基本上添加/删除我的“盐”并让框架管理实际的令牌验证。这样对我来说管理起来就少了一点。一旦我确认这是有效的，将发布更多详细信息。

Answer 4

所以这将是我不喜欢的“你做错了”的答案之一，所以我先道歉。无论如何，从问题和 cmets 来看，我将建议您以不同的方式解决问题。与其考虑请求来自何处，不如考虑请求试图做什么。您需要确定用户是否可以这样做。

我猜为什么这对你来说很难，我认为你的 api 接口太通用了。从您的示例 api“api/common/update”中，我猜您有一个可以更新任何内容的通用更新 api，并且您希望保护从只应该访问数据 Y 的页面更新数据 X。如果我离开基地然后不理我。 :)

所以我的回答是：不要那样做。更改您的 api，使其从您要使用的数据开始：api/dataX api/dataY。然后使用用户角色适当地保护这些 api 方法。在幕后，您仍然可以有一个通用的更新例程，如果您喜欢它并且它对您有用，但请保持 api 接口更加具体。

如果您真的不想为每个表都有一个 api，并且如果它适合您的情况，也许您至少可以有一个用于受保护/管理表的 api 和一个用于标准表的单独 api。很多“如果”，但也许这对你的情况有用。

此外，如果您的用户可以更新某些 dataX 但不能更新其他 dataX，那么您将必须对您的数据进行某种检查，最好是针对某个根对象以及您的用户是否有权查看/使用该根对象.

总而言之，避免使用过于通用的 api 接口。通过更具体，您可以使用现有的安全工具来帮助您。

祝你好运！