Rails安全导读【二】

Rails安全导读【二】2011-07-18 51cto博客 blackanger译可以接着上一章来看：

三 Cross-Site Reference Forgery （CSRF）

－这个攻击方法包含恶意代码或是一个用户信任的已验证的web应用页面的链接。如果session没有过期，攻击者就可能执行未授权的命令。

在session那一章里，你已经了解，大多数的Rails应用都使用基于cookie的session。要么他们在cookie里存储一个session id，服务端有个session hash，要么整个session hash都在客户端。当向一个域名发送请求时，如果能找到这个域名的cookie，浏览器会自动附带上这个 cookie。但是，问题是，来自于不同域名的站点的请求，也会发送这个cookie。来看这个例子：

1.Bob同志浏览了一个留言板和一个由hacker制作的html标签内容。这个元素引用的是一个bob的项目管理应用程序里的命令，而不是一个图片。

2.<img src="http://www.webapp.com/project/1/destroy">

3.Bob的session在www.webapp.com还是活的,因为他刚刚离开几分钟还没有注销。

4.当浏览器发现这个img标签，他试图从www.webapp.com加载这个图像，正如前面所说，他将会发送一个带有有效session id的cookie（bob 的cookie，他刚登陆www.webapp.com）。

5.位于www.webapp.com的web应用验证了对应session hash的用户信息并且删除了id为一的那个project。之后它返回了一个出乎浏览器意料的结果，所以它没有显示图像。

6.Bob并没有注意到这次攻击，但是一些天以后，他发现id为一的那个project离他而去了。

有重要的一点要注意，实际制作的图像或链接不一定必须位于Web应用的网域，它可以在任何地方-在一个论坛，博客帖子或电子邮件。

CSRF是一个不可忽略的重要的安全问题。

3.1 CSRF对策

－第一点，遵循W3C标准，正确使用GET和POST，第二点，在non－GET请求中使用一个安全token将使你远离CSRF.

HTTP协议提供两种类型的请求－ GET和POST（还有其他，但是大多数浏览器不支持），万维网联盟（ W3C ）为HTTP GET或POST提供了一个选择清单：

Use GET if:

这个Interaction更像是问题，它是一个安全操作，比如，如查询，读操作，或查阅

Use POST if:

这个Interaction更像是命令，或者

这个Interaction依用户期望的方式改变资源状态，比如订阅一个服务。

用户为这个interaction产生的结果负责。

如果你的应用是restful的，你可能会用额外的http动词，例如 PUT ,DELETE。然而今天大多数的浏览器并不支持它们，仅仅支持GET和 POST。Rails使用一个隐藏的_method来处理这一障碍（我在这篇文章http://blackanger.blog.51cto.com/140924/108678最后一段引用DHH的话也说过）。

在一个controller里的验证方法确保具体的actions不会过度使用GET.