Rails动态模板路径的风险

[[172440]]

前言

从安全开发的角度来看,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)。怎么说呢?我们直接看下去。

基本细节

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

  1. # app/controllers/welcome_controller.rb 
  2. class WelcomeController < ApplicationController 
  3.   def index 
  4.     page = params[:page] || 'index' 
  5.     render page 
  6.   end 
  7. end 

而index的模版内容是这样:

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

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

  1. # app/views/welcome/demo.html.erb 
  2. 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的上传纪录。如下:

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

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

  1. #{params[:devcore]} 

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

 

  1. # log/production.log 
  2. 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") 
  3.  
  4. 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。

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

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

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

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

结论

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

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

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/147855.html<

(0)
管理的头像管理
上一篇2025-03-11 21:25
下一篇 2025-03-11 21:27

相关推荐

  • 云服务器和云虚拟主机怎么选?云服务器和虚拟主机区别

    云服务器适合业务增长快、需弹性扩展的场景,而云虚拟主机适合预算有限、技术门槛低的小型静态网站或测试环境,二者核心区别在于资源独享性与运维复杂度,核心差异解析:从底层架构到使用体验很多人容易混淆这两者,觉得它们都是“买空间建站”,它们的底层逻辑完全不同,云服务器(ECS)就像是你租了一整栋别墅,水电网络独立,你想……

    2026-06-29
    0
  • 赣州智慧旅游招聘是真的吗?赣州旅游人才招聘信息

    中级岗位(3-5年经验)月薪范围通常在6000-10000元,这类岗位需要独立负责项目模块,如独立运营一个抖音账号,或维护一个景区小程序的功能迭代,具备成功案例的候选人议价能力较强,高级岗位(5年以上经验)月薪范围通常在10000-20000元,部分核心管理岗可达更高,这类人才需要具备战略规划能力,如制定整个景……

    2026-06-29
    0
  • 赣州智能物联网车位锁如何管理?智能车位锁管理系统多少钱

    赣州智能物联网车位锁管理的核心在于通过云端平台实现远程控锁、状态实时监控及自动计费,彻底解决传统车位“被占难管”与“找位难”的痛点,在赣州这样的城市,随着机动车保有量的持续增长,老旧小区、商业综合体以及私人固定车位的资源矛盾日益凸显,传统的机械地锁或简易遥控锁,不仅操作繁琐,更无法实现数据化管理,引入智能物联网……

    2026-06-29
    0
  • 赣州智能消防栓好用吗,智能消防栓多少钱一个

    赣州智能消防栓通过物联网技术实现实时监测与远程报警,能显著降低火灾响应时间并提升城市消防安全管理水平,是目前智慧城市建设中不可或缺的基础设施,赣州智能消防栓的核心价值与应用场景传统消防栓往往存在“看不见、摸不着、用不了”的痛点,在赣州这样地形复杂、老城区与新城区并存的区域,传统设施的管理难度极大,智能消防栓的出……

    2026-06-29
    0
  • 云服务器和物理机到底有啥区别?

    云服务器本质上是虚拟化资源池中的弹性实例,而传统物理服务器是独占的硬件实体,前者胜在弹性与运维便捷,后者强在物理隔离与性能稳定,具体选择取决于业务对成本、扩展性及安全合规的权衡,很多人初次接触服务器时,容易把“云服务器”和“传统物理服务器”混为一谈,觉得它们都是用来跑网站或存数据的盒子,这两者的底层逻辑完全不同……

    2026-06-29
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注