所属类别：开发技术

文章作者：blackanger

特别推荐：免费发布信息 承包关键词~~抢爆了！^HOT!

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://blackanger.blog.51cto.com/140924/110952可以接着上一章来看：三 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.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.来看一个例子，仅在transfer 这个action里使用post方法，如果使用了其他的HTTP动词，则会被重定向到list 这个action：verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}这个防范措施，使攻击失效，因为web应用不会接受浏览器从images发送的一个get请求。但这仅仅是第一步，因为post请求也可以被自动发送。下面的一个例子可以动态创建一个发送post请求的form表单：To the harmless survey或者，攻击者可以把这些代码放在图片的鼠标滑过事件处理里面：这里还有很多可能性，包括在后台对受害者进行ajax攻击。解决的办法是在服务端对非GET请求使用security token， 在Rails2.x 版本，只需要在application controller里加一行代码：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的内容奉献。本文出自 51CTO.COM技术博客

....