PHPF中的CSRF(跨站点请求伪造)攻击示例和预防

Question

我有一个网站,人们可以这样投票:

http://mysite.com/vote/25

这将对项目25进行投票.我想只为注册用户提供此选项,并且只有在他们想要这样做时才可以.现在我知道有人在网站上忙碌,有人给他们这样的链接:

http://mysite.com/vote/30

然后投票将是他在项目上的位置,而他不想这样做.

我已经阅读了OWASP网站上的解释,但我真的不明白

这是CSRF的一个例子,我该如何防止这种情况发生.我能想到的最好的事情就是像哈希一样在链接中添加一些内容.但是,在所有链接的末尾添加一些内容会非常恼人.没有其他方法可以做到这一点.

另一件事可能有人可能会给我一些其他的例子,因为该网站对我来说似乎是相当的神话.

Answer 1

如果符合以下条件,这可能成为CSRF的一个例

• 获取该链接(<img>例如通过标记):伪造
• 从另一个站点:跨站点

例如,如果我可以<img>在stackoverflow的HTML源代码中注入此标记(我可以,因为stackoverflow允许<img>在他的帖子中使用标记):

<img src="http://mysite.com/vote/30" />

你只会投票支持该项目;-)

通常使用的解决方案是在URL中放置生命周期有限的令牌,并在获取URL时检查此令牌是否仍然有效.

基本想法是:

• 生成页面时:
  • 生成一个唯一的令牌
  • 将其存储在用户的会话中
  • 并将其放在页面的链接 - 这将是这样的: http://mysite.com/vote/30?token=AZERTYUHQNWGST
• 调用投票页面时:
  • 检查URL中是否存在令牌
  • 检查它是否存在于用户的会话中
  • 如果不=>不注册投票

这个想法是:

• 令牌没有很长的使用寿命,很难猜测
• 这意味着你的攻击者:
  • 只有几分钟的窗口,在此期间他的注射将是有效的
  • 必须善于猜测^^
  • 必须为每个用户生成不同的页面.

此外,请注意,用户会话离开您的网站后保持活动时间越短,访问不良网站时仍然有效的风险就越小.

但在这里,您必须在安全性和用户友好性之间做出选择......

另一个想法(那不是非常安全,但有助于反对家伙不知道如何强制POST请求),只会在人们投票时接受POST请求:

• 浏览器正在发送注入标签的GET请求
• 由于此URL正在修改某些数据,无论如何,它不应该与GET一起使用,而只能与POST一起使用

但请注意,这不是完全安全的:它可能(可能？)可能强制/伪造一个POST请求,有点Javascript.

Answer 2

首先,不应该使用GET请求来改变服务器上的状态,因此对于您的投票服务,我建议使用POST/PUT.这只是一个指导方针,但却是一个切肉刀.

因此,对于您的问题,CSRF是一个客户端问题,因此您使用何种服务器语言并不重要(在您的情况下为PHP).标准修复是相同的,如下所示:在URI/POST数据中有一个随机值,在Cookie标头中有相同的值.如果这些匹配你可以确定没有CSRF.有关如何在StackOverflow上完成此操作的信息很多,例如.这个.
祝好运!

Answer 3

OWASP有一个用于PHP的CSRFGuard,以及我很久以前为XMB写的ESAPI for PHP - > UltimaBB - > GaiaBB.

http://code.google.com/p/gaiabb-olpc/source/search?q=function+get_new_token&origq=function+get_new_token&btnG=Search+Trunk

似乎其他一些人已经清理了该代码并允许更强的令牌:

https://www.owasp.org/index.php/PHP_CSRF_Guard

谢谢,安德鲁