可以接着上章来看:

　　 3　Cross-Site Reference Forgery (CSRF)

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

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

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

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

　　3.Bobsession在www.webapp.com还是活,他刚刚离开几分钟还没有注销

　　4.当浏览器发现这个img标签他试图从www.webapp.com加载这个图像正如前面所说他将会发送个带有有效session idcookie(bobcookie 他刚登陆www.webapp.com)

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

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

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

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

　　3.1　CSRF对策

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

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

　　Use GET :

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

　　Use POST :

　　这个Interaction更像是命令或者

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

　　用户为这个eraction产生结果负责

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

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

　　来看个例子仅在transfer 这个action里使用post思路方法如果使用了其他HTTP动词则会被重定向到list 这个action:

protect_from_forgery :secret ⇒ "123456789012345678901234567890…"

　　它会在所有Rails里生成表单和ajax请求里自动包含个根据当前session和服务端secret计算出来security token 你用CookieStorage作为session 存储就不需要这个secret了 如果这个security token和所期望不匹配就会抛出个ActionController::InvalidAuthenticityToken 异常

　　请注意跨站点脚本(xss)漏洞绕过所有CSRF保护XSS可以让攻击者访问页面所有元素所以他可以从个表单里读取CSRF Security token, 或者直接提交表单稍后会有更多xss内容奉献