【问题标题】:Understanding ASP.NET MVC anti-forgery protection了解 ASP.NET MVC 防伪保护
【发布时间】:2012-12-13 22:52:16
【问题描述】:

在我的所有表单都有@Html.AntiForgeryToken() 的基本 MVC 项目中,我见证了特定用户会话的 所有 表单的令牌 (cookie) 值始终相同。这是为什么?我部分理解这一点(否则会有很多问题,例如后退按钮)。但是为什么不使用“salt”为不同的形式做出不同的选择:

“此方法已弃用。请改用 AntiForgeryToken() 方法。 要指定要嵌入到令牌中的自定义数据,请使用静态 AntiForgeryConfig.AdditionalDataProvider 属性。”

为什么它这么大(在我的示例中为 207 个字节,用户身份名称为 7 个字符)?标准会话 ID 更短 (41)。

【问题讨论】:

  • AntiForgeryToken 不是隐藏的表单值吗?
  • 是的。但是生成的令牌存储在 cookie 和隐藏字段中。在发布时,它们的值必须相同才能通过验证。

标签: asp.net .net asp.net-mvc-3 security


【解决方案1】:

它只需要对用户会话唯一的原因是由于针对 CSRF 漏洞的利用如何工作;

本质上,CSRF 依赖于恶意用户提前设置的表单值。恶意用户只能设置表单值,通常作为 GET 参数;他们无法获取/读取合法表单上可能存在的值,并且他们无法可靠地猜测任何用户的 207 长度代码。

如果存在 XSS 漏洞,恶意用户可以通过某种方式获取此“实时”信息,则例外情况。但是由于存在 XSS 漏洞,无论如何都不需要使用 CSRF。

因此,只要每个用户会话都有其独特的价值,恶意用户实际上就不可能提前制作适当的表单提交。

【讨论】:

  • 为什么仍然存在带有盐的“AntiForgeryToken()”重载?
  • @UserControl 我想只是为了让您能够添加独特的功能,如果您愿意的话。我无法想象一种需要它的网络应用程序,但我想他们只是想考虑这种可能性。或者也可能只是为了增加令牌的随机性。
  • 知道了!大小有猜吗?为什么不只是散列会话 id?
  • 我不确定尺寸;也许只是为了使它尽可能难以猜测。似乎与 Session ID 大小相当的东西会起作用,但是......至于它基于 Session ID,我最好的 猜测 这样做会使它(略微)更可预测.尽管对我来说这似乎仍然很弱!所以我真的只能猜测:让猜测变得更加困难!
猜你喜欢
  • 2017-12-28
  • 1970-01-01
  • 1970-01-01
  • 2014-04-26
  • 2012-06-29
  • 2019-06-09
  • 2015-03-12
  • 1970-01-01
  • 2015-01-11
相关资源
最近更新 更多