可以接着上一章来看：
三 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.
