首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >针对CSRF保护登录和评论表单

针对CSRF保护登录和评论表单
EN

Stack Overflow用户
提问于 2013-03-26 08:45:46
回答 4查看 2.4K关注 0票数 6

我已经读过很多关于CSRF保护(这是一个很好的)的文章,以及关于这些问题的各种问题,但是它们似乎都没有足够的信息来回答我的问题。

我正在开发我自己的CMS,我想确保我的登录和评论表格。我将允许匿名用户在我的网站上发表评论。

我网站上的所有表单都是使用令牌进行保护的。我已经知道了这种方法,但问题是它需要一个活动会话(即在用户登录之后)。登录和评论表单的问题是,几乎任何人都可以访问它们,并且不要求您登录--在这种情况下,什么才是防止CSRF的最佳保护措施?

在上面的链接上,我读到,当用户尝试登录,然后继续使用通常的反CSRF方法(比如为用户的会话分配令牌)时,可以创建一个“预会话”,但我对如何实现这一点没有深入的见解。

引用头是一个弱的解决方案,所以我想我不应该麻烦。据我所测试,原产地标头只支持谷歌Chrome。那自定义标题呢?XMLHTTPRequest似乎是一种可能性,然而,我已经花了三个多小时在谷歌上查找一些关于如何在他们的网站上实施这样的安全措施的信息。但是,即使我可以使用一个自定义报头,它难道不使它无用吗,因为HTTP报头可以完全伪造?

那么,问题是:我应该如何保护我的登录和评论表格免受CSRF的影响?

编辑:,以下是我上面提供的链接中的一些附加信息:

我们建议进行严格的引用验证,以防止登录CSRF,因为登录表单通常是通过HTTPS提交的,在HTTPS上,引用程序头可靠地存在于合法请求中。如果登录请求缺少引用标头,则站点应拒绝该请求,以防止恶意抑制。

秘密验证令牌可以抵抗登录CSRF,但是开发人员经常忘记实现防御,因为在登录之前,没有会话可以绑定CSRF令牌。要使用秘密验证令牌来防止登录CSRF,站点必须first创建一个“presession”,实现基于令牌的CSRF保护,然后在成功的身份验证之后转换到一个真正的会话。

我只是在读了上面的引语之后,不能结束这个论点。其中一位提到使用referrer,但我不太确定它是否真的增加了webapp应用程序的安全性。

编辑2:使用CAPTCHA怎么样?

EN

回答 4

Stack Overflow用户

回答已采纳

发布于 2013-03-26 08:56:12

CSRF问题涉及使用登录用户凭据提交某些内容的人。这是一个很大的问题,因为一个恶意网站可以做的东西,谁刚刚浏览到您的网站。如果您谈论的表单可以作为匿名形式使用,而无需登录,那么CSRF风险就会大大降低,因为从另一个站点发布到表单可以获得的收益要少得多--因为任何人都可以直接使用相同的权限。

所以我不明白为什么不登录的表单需要对CSRF进行保护。

如果您确实希望这样做,则会前令牌在技术上可能与实际会话相似,但只是重量更轻的令牌。除了生成的令牌之外,它不会包含其他任何内容。

编辑:关于使用PHP提供的$_SESSION作为会前令牌,这是PHP的标准会话机制。如果你想用这个,那么是的,就这样。

然而,您并没有被迫这样做,而且我个人也不会这样做,因为它消耗了所有访问者的服务器内存,这并不是真正需要的。为了更有效的机制,基本上您需要( a)一个cookie标识用户,b)存储在服务器端的东西告诉cookie是有效的(如果需要的话,它对谁有效,意味着ip)。对于一种更轻量级的方法,您只需创建一个令牌,将其存储在cookie中,并在表单中生成与该令牌匹配的内容作为隐藏字段,并与submit上的标记匹配(如Devesh所解释的)。后者将防止从另一个站点提交表单,前者甚至可以防止恶意站点对您的站点进行查找并尝试向最终用户设置任何cookie的情况。所以我可以想到三种方法:

  • 只需防止来自其他站点的图像请求--使用POST可以防止这一点。
  • 防止表单从另一个站点提交-表单隐藏字段匹配cookie防止此
  • 防止从另一个站点提交对您的站点进行预查找的表单--这需要IP验证,即存储在服务器端的内容,比如与cookie匹配的数据库中的ip。

EDIT2:在captchas上,它们的主要用例是防止自动(蛮力)登录尝试。他们也会在登录表单上解决CSRF请求的问题,但这是一个过分的问题。为了防止蛮力的登录攻击,在某些情况下可能需要使用它们,尽管为了不过分降低可用性,更友好的用户可能会使用它们。也许类似于KittenAuth :)

票数 3
EN

Stack Overflow用户

发布于 2013-03-26 08:55:53

您无法真正保护匿名表单不受CSRF的影响。仅仅是因为另一个站点可以充当一个常规用户。我只需创建一个站点,对匿名表单执行curl请求,并将cookie和令牌存储在变量中。然后第二次请求发布表单。这个脚本不是真正伪造一个请求,而是自动投递。

CSRF的目的是防止脚本/人员代表另一个用户执行操作。所以那将是我试着以你的身份发布。为了防止使用令牌方法的会话/cookie,是一个很好的解决方案。因为我没有办法得到您的会话和令牌,除非您的网站在其他领域有缺陷。我建议阅读OWASP指南,以了解您应该注意的内容。

另一件你应该做的事情是确保“动作”总是与POST请求,所以我不能简单地放在你的论坛上链接到'http://www.yoursite.com/delete.php?id=10‘的图片。如果您允许GET请求并打开包含此图像的页面,我将伪造一个请求。如果您只允许POST,它将没有结果。

票数 0
EN

Stack Overflow用户

发布于 2013-03-26 09:00:59

我认为您可以通过合并添加到表单中的隐藏字段来解决CSRF类型的问题,同时在cookie中添加相同的值并附加到用户响应中。当用户回发表单时,尝试匹配来自请求的隐藏字段值和cookie值,如果两者都匹配,则可以选择.

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/15632700

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档