7

以前的HtmlHelper.AntiForgeryToken允许一个人覆盖的string path方法已被弃用。

[ObsoleteAttribute("This method is deprecated. Use the AntiForgeryToken() method instead. To specify a custom domain for the generated cookie, use the <httpCookies> configuration element. To specify custom data to be embedded within the token, use the static AntiForgeryConfig.AdditionalDataProvider property.", 
    true)]
public MvcHtmlString AntiForgeryToken(
    string salt,
    string domain,
    string path
)

告诉你使用<httpCookies>. 但是httpCookies 元素没有 PATH 的设置。

这是弃用此方法的疏忽吗？覆盖此 cookie 路径的最佳方法是什么？（手动？）在虚拟应用程序中运行网站不会将应用程序路径隐式添加到 __RequestVeririfcation cookie。

4

3 回答 3

3

查看弃用消息：

“此方法已弃用。请改用 AntiForgeryToken() 方法。要为生成的 cookie 指定自定义域，请使用配置元素。要指定要嵌入到令牌中的自定义数据，请使用静态 AntiForgeryConfig.AdditionalDataProvider 属性。”

它告诉我们，只要读回伪造令牌，我们就可以验证其他参数。所以即使我们无法在 cookie 中设置路径，我们也可以将路径设置为令牌内部的属性。稍后验证它，例如：

public class AdditionalDataProvider : IAntiForgeryAdditionalDataProvider
{
    public string GetAdditionalData(HttpContextBase context)
    {
        return AdditionalData(context);
    }

    public bool ValidateAdditionalData(HttpContextBase context, string additionalData)
    {
        var currentData = AdditionalData(context);
        return currentData == additionalData;
    }

    private static string AdditionalData(HttpContextBase context)
    {
        var path = context.Request.ApplicationPath;
        return path;
    }
}

当 asp.net 生成令牌时，它将存储该应用程序的当前路径（或您要验证的任何其他唯一值），如果您有另一个应用程序在不同的路径上运行，则当令牌被发送到该应用程序时（由于缺少 cookie 路径）它将根据该应用程序的属性验证以前的应用程序属性。如果它是一组不同的属性，它将失败并拒绝请求。

此外，查看AntiforgeryConfig.cs的代码，如果应用程序在虚拟目录中运行，它将默认将该虚拟目录添加到 cookie 的名称中：

private static string GetAntiForgeryCookieName()
{
    return GetAntiForgeryCookieName(HttpRuntime.AppDomainAppVirtualPath);
}

// If the app path is provided, we're generating a cookie name rather than a field name, and the cookie names should
// be unique so that a development server cookie and an IIS cookie - both running on localhost - don't stomp on
// each other.
internal static string GetAntiForgeryCookieName(string appPath)
{
    if (String.IsNullOrEmpty(appPath) || appPath == "/")
    {
        return AntiForgeryTokenFieldName;
    }
    else
    {
        return AntiForgeryTokenFieldName + "_" + HttpServerUtility.UrlTokenEncode(Encoding.UTF8.GetBytes(appPath));
    }
}

所以它会是这样的： _RequestVerificationToken vs _RequestVerificationToken _L2RIdjAz0

意思是 App2 虽然可以从 App1 接收令牌，但它无法读取它们，因为它将始终只寻找 App2 验证令牌。

高温高压

于 2016-07-01T12:35:24.533 回答
2

对于 ASP.NET Core - 请参阅：AntiforgeryOptions 类

Cookie - 确定用于创建防伪 cookie 的设置。

Ex（改编自ASP.NET Core 中的防止跨站点请求伪造（XSRF/CSRF）攻击）：

services.AddAntiforgery(options => 
{
    options.Cookie.Path = "Path";
});
于 2018-08-21T20:45:13.820 回答
2

覆盖 AntiForgeryToken 的 cookie 配置（Path、HttpOnly、...）的最佳方法是封装（Microsoft team post）。

可以配置 cookie 路径而不是在属性上设置它。

public static class AntiForgeryTokenExtensions
{
    ///<summary>
    ///Generates a hidden form field (anti-forgery token) that is 
    ///validated when the form is submitted. Furthermore, this extension 
    ///applies custom settings on the generated cookie. 
    ///</summary>
    ///<returns>Generated form field (anti-forgery token).</returns>
    public static MvcHtmlString AntiForgeryTokenExtension(this HtmlHelper html)
    {
        // Call base AntiForgeryToken and save its output to return later.
        var output = html.AntiForgeryToken();
        
        // Check that cookie exists
        if(HttpContext.Current.Response.Cookies.AllKeys.Contains(AntiForgeryConfig.CookieName))
        {
            // Set cookie into the variable
            var antiForgeryTokenCookie = HttpContext.Current.Response.Cookies.Get(AntiForgeryConfig.CookieName);
            
            // Set cookie configuration
            antiForgeryTokenCookie.Path = "/Path";
            // antiForgeryTokenCookie.HttpOnly = true;
            // ...
        }
        
        return output;
    }
}

必须完成最后一项更改，如果它是现有项目，则将 AntiForgeryToken ()替换 为AntiForgeryTokenExtension()。

笔记

  • 使用此代码，您可以将 AntiForgeryToken cookie 配置为普通 cookie。
  • 也可以向此方法添加输入参数，但我不确定这是否是一个好习惯。
  • 有不同的方法来获取 cookie，但我认为通过 Response.Cookies 是“最正确的”，因为它是一个响应 cookie。

重要的

在尝试获取它之前，需要先检查 cookie 是否存在。如果您尝试获取一个不存在的响应 cookie，它将被生成。请求 cookie 不会发生这种情况。

饼干知识

这不是问题本身，而是解释了部分代码，知道我们何时使用 cookie 非常重要，所以我认为在这里也有这些信息是件好事。

  • 所有Response.Cookies都在Request.Cookies中，但并非所有 Request.Cookies都在Response.Cookies中。

  • 如果您创建一个Response.Cookie，它也会出现在Request.Cookies中。

  • 如果您创建Request.Cookie，它将不会出现在Response.Cookies中。

  • 如果您尝试从Request.Cookies获取不存在的 cookie，它将返回 null。

  • 如果您尝试获取一个不存在的 cookie Response.Cookies，它将返回一个新生成的 cookie。

来源

有开发人员告诉使用封装和许多其他可能有用的东西的链接。 Microsoft 开发人员建议和信息

cookie 知识来源，Request.Cookies 和 Response.Cookies 的区别。

请求 cookie 和响应 cookie 之间的区别

请求cookies和响应cookies的区别2

检查cookie是否存在以及cookie类型之间的区别

于 2021-10-31T14:25:54.367 回答