asp.net-mvc-3 – 当不需要/需要使用AntiForgeryToken时?

前端之家收集整理的这篇文章主要介绍了asp.net-mvc-3 – 当不需要/需要使用AntiForgeryToken时?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
UPD: security.stackexchange.com问同样的问题,我得到的答案是不同的。请跟着那里,得到正确的答案!

我正在运行一个相当大的站点,每天都有数千次访问,并且有一个相当大的用户群。

自从我开始迁移到MVC 3之后,我一直在使用多种形式的AntiForgeryToken来修改受保护的数据。

一些其他形式,如登录/注册,现在也使用AntiForgeryToken,但是我首先对他们的需求变得疑惑,有几个原因…

>登录表单要求海报知道正确的凭据。我真的不能想到任何一种csrf攻击将在这里受益。特别是如果我检查请求是从同一个主机(检查引荐来源头)
> AntiForgeryToken标记在每次加载页面时都会生成不同的值。如果我有两个标签打开登录页面,然后尝试发布,第一个将成功加载。第二个将使用AntiForgeryTokenException(首先加载两个页面,然后尝试发布它们)将失败。使用更安全的页面 – 这显然是一个必要的邪恶,登录页面 – 似乎是过分的,只是要求麻烦:S

可能有其他原因为什么会使用/不使用它们的形式的令牌。我假定在每个帖子形式中使用令牌是坏的/过度的,如果是 – 什么样的形式将从中受益,哪些不会受益?

解决方法

防伪令牌在用户尚未认证的站点的公共部分(如登录注册表单)中是无用的。 CSRF攻击的工作原理如下:

恶意用户在他的网站上设置一个类似于您的站点的HTML表单。此表单也可能包含隐藏字段。
他欺骗你的一个网站用户访问他的恶意网址。
>用户认为他在您的网站上,填写表单并将其提交到您的网站。
>如果用户已经在您的网站上进行身份验证,则表单提交成功,并且无人知晓的用户删除其帐户(或任何您可以想像的)。

因此,您可以在网站的身份验证部分使用防伪令牌,其中包含可以以某种方式修改用户状态的操作。

注意:检查参考标题以确定来自您的站点的请求是不安全的。任何人都可以伪造一个请求并欺骗这个头。

猜你在找的asp.Net相关文章