我的MVC应用程序有常见的aplog方法（在web API和常规控制器中）。我想根据调用来自我的应用程序的哪个区域（视图）来授权这些调用。我面临的问题是如何验证aplog调用的来源。
我意识到这并不容易实现，因为aplog调用很容易被欺骗，但由于我完全控制了视图的呈现方式（整页源代码），也许有一种方法可以嵌入防伪类型的令牌，稍后可以验证到URL引用。
身份验证已经被处理，我可以安全地验证调用的身份，唯一的问题是验证调用来自哪个URL（MVC路由）。更具体地说，防止用户能够欺骗aps调用的起源。
我试着创建一个自定义的授权头，并在视图呈现和apache调用之间传递它，这很有效，但仍然很容易被欺骗（因为用户可以从网站的另一部分嗅探头部并重用它们）。最后，我不知道如何安全地验证头部没有被欺骗。唯一想到的是在令牌中编码一些关于原始上下文的信息，并以某种方式根据传入的调用上下文（在一个传入的调用中传递令牌的上下文）验证它。
我看到MVC有防伪令牌功能，但我不确定这是否能解决我的问题。如果是这样，我想知道如何使用它来验证/api/common/update是从/home/index和/user/setup调用的（这两个调用都是有效的）。
同样，我希望有一种方法来验证哪个页面的一个apache调用是来自，用户身份不是问题。

更新

根据@Sarathy的建议，我尝试实现了防伪token。据我所知，这是通过在每个页面上添加一个带有token的隐藏字段，并将其与cookie中的token进行比较来实现的。下面是我实现的自定义action filter属性，它可以进行token验证：

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;
    }

型
这是可行的，因为我可以看到正确的页面记录在提供商，和防伪打破了w/出令牌。
然而，除非我做错了什么，否则这似乎是微不足道的欺骗。例如，如果我转到pageA并从pageB复制token（只是表单token，甚至没有cookie token），这仍然成功，并且在我的日志中，我看到pageB同时执行来自pageA的appropriate方法

我使用csrf来生成如下的aScore令牌：

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;
    }

型
然后，我在每次调用apache时将表单标记传递回去，并拥有一个自定义的actionfilter属性，在该属性中，我将沿着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在每个页面加载时都不同，则可以使用这种方法