Rails安全导读【二】

可以接着上一章来看：

三　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.

Rails安全导读【二】(2)

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

verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}

这个防范措施，使攻击失效，因为web应用不会接受浏览器从images发送的一个get请求。但这仅仅是第一步，因为post请求也可以被自动发 送。下面的一个例子可以动态创建一个发送post请求的form表单：

<a href="http://www.harmless.com/" onclick=" 　　var f = document.createElement (''form''); 　　f.style.display = ''none''; 　　this.parentNode.appendChild(f); 　　f.method = ''POST''; 　　f.action = ''http://www.example.com/account/destroy''; 　　f.submit(); 　　return false;">To the harmless survey</a>

或者，攻击者可以把这些代码放在图片的鼠标滑过事件处理里面：

<img src="http://www.harmless.com/img" width="400" height="400" onmouseover="…" />

这里还有很多可能性，包括在后台对受害者进行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的内容奉献。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!