Rails动态模板路径的风险-动态路径的规划

前言

从安全开发的角度来看，Ruby on Rails是一套很友善的框架。它从框架层避免了很多过去网站长出现的安全问题。例如使用ORM避免大部分的SQL injection问题，有内建的authenticity_token让开发者不必特别烦恼CSRF，从机制面规定了开发者使用Strong Parameter来避免Mass Assignment，预设转化危险字符避免XSS等。

就我们从过去的渗透测试的经验来看，Rails网站虽然还是能找到问题，但相对问题较少，而且很少单纯因为Rails写法问题拿到系统权限。而今天要分享的，是一次渗透测试中比较特别的例子。因为开发者使用了动态模板路径(Dynamic Render Paths)的写法(注解1)，最后造成了严重的结果。

动态模板路径，OWASP的介绍是这样的：

OWASP是这样说，如果你的模板路径是动态产生的，而且使用者可以控制那个模板路径。那么使用者就可以读取任意模板，包括管理界面模板。这样的描述感觉还好，但就我们的发现，这其实是严重的直接存取物件问题(Insecure Direct Object References)，甚至有机会造成远程代码执行(Remote Code Execution)。怎么说呢?我们直接看下去。

基本细节

一个动态模版路径的写法如下：

# app/controllers/welcome_controller.rb 
class WelcomeController &lt; ApplicationController 
  def index 
    page = params[:page] || 'index' 
    render page 
  end 
end

而index的模版内容是这样：

<span class="c">#app/views/welcome/index.html.erb 
This is INDEX page.</span>

另外建一个demo模版做示意：

# app/views/welcome/demo.html.erb 
This is DEMO page.

实际测试，如果我们连到WelcomeController的index action，不带任何参数会读取index模版。

如果带参数page=demo，会读取到demo模版。

所以，如果我们知道管理界面的模版路径，送出路径参数就可以读取到管理界面。这就是OWASP所描述的风险，攻击者得以读取任意模版。

然而，当我们尝试送出系统绝对路径例如/etc/passwd(注解2)，网页竟然显示/etc/passwd的内容!这就是之前所述的直接存取物件问题，可以遍历目录浏览档案。

进阶攻击

通常在Rails环境下能够读取任意档案，攻击者会优先寻找secret_token，目的是变造恶意session cookie利用Marshal serialize的问题做RCE。然而在本案例系统使用了Rails 4.1后的版本，Rails 4.1预设使用了JSON-based的serializer防止了之前的RCE问题，所以并没有办法轻松利用。

为了取得系统操作权，我们尝试寻找其他可利用的地方。在这边我们发现了该站系统production.log中存在AWS的上传纪录。如下：

# log/production.log 
INFO -- : [AWS S3 200 0.041347 0 retries] put_object(:acl=&gt;:public_read,:bucket_name=&gt;"xxx

于是我们可以利用上传档案的Content-Type内容，将Embedded Ruby语句<%

#{params[：devcore]}

%>添加到production.log档案里面。于是log的内容变成了下面这样：

# log/production.log 
INFO -- : [AWS S3 200 0.041347 0 retries] put_object(:acl=&gt;:public_read,:bucket_name=&gt;"xxxx",:content_length=&gt;12405,:content_type=&gt;"image/png",:data=&gt;#&lt;File:/Users/shaolin/project/playground/rails/render/public/uploads/tmp/test_upload.png (12405 bytes)&gt;,:key=&gt;"upload_001") 
 
INFO -- : [AWS S3 200 0.040211 0 retries] put_object(:acl=&gt;:public_read,:bucket_name=&gt;"xxx

接着，我们就可以利用前面的弱点读取production.log档案，再带一个devcore参数作为指令，如图，成功取得系统权限：

风险原因

一般来说Rails开发并不太会这样写，但稍微搜寻一下Github还是能发现这种写法存在一些项目中。我想主要原因多半是开发者想要偷懒，然后也可能想说动态模板路径顶多就被看到面板的html，无伤大雅。谁知道就因为这样导致整个代码内容被读取。

若有一个action要动态显示不同模版的需求，为了避免上述的问题，就辛苦点先用case…when去判断吧。这跟不要用字串组SQL语句避免SQL injection一样，这种外面传进来的参数都要谨慎处理的观念要内化在开发中。

除了开发者基本上不应该这样开发外，Rails本身也有一点点问题，当render路径没有扩展名，无法判断什么格式时，就会直接采用预设的template handler。

# lib/action_view/template/resolver.rb 
def extract_handler_and_format_and_variant(path, default_formats) 
  pieces = File.basename(path).split(".") 
  pieces.shift 
 
  extension = pieces.pop 
  unless extension 
    message = "The file #{path} did not specify a template handler. The default is currently ERB, " \ 
              "but will change to RAW in the future." 
    ActiveSupport::Deprecation.warn message 
  end 
 
  handler = Template.handler_for_extension(extension) 
  format, variant = pieces.last.split(EXTENSIONS[:variants], 2) if pieces.last 
  format  &amp;&amp;= Template::Types[format] 
 
  [handler, format, variant] 
end

而这里预设的handler是ERB(见register_default_template_handler)，所以有本篇后面提到的进阶攻击，可以被利用来RCE。

# lib/action_view/template/handlers.rb 
def self.extended(base) 
  base.register_default_template_handler :erb, ERB.new 
  base.register_template_handler :builder, Builder.new 
  base.register_template_handler :raw, Raw.new 
  base.register_template_handler :ruby, :source.to_proc 
end

庆幸的是，目前Rails已经把预设的template handler从ERB改成RAW，不会轻易把要render的档案当成ERB执行了。详细的内容请参考这个commit。

结论

Ruby on Rails能让开发者较轻松的开发出安全的应用程序，然而，若开发者不注意，还是有可能写出严重的漏洞。本文的动态样板路径就是这样一个例子，它不只是OWASP所描述的可以存取任意模版而已，它可以遍历档案，甚至因为rails预设的template handler是ERB，造成远程代码执行让攻击者取得服务器操作权。

这个例子又再次验证，框架可以帮助大家快速开发，增加安全度。但唯有良好的安全意识，才是应用程序安全的基石。