Ruby 最佳实践

概述

Ruby 程序语言的安全性原则，主要聚焦於 Ruby on Rails Web 框架。

注意事项

• 跨站请求伪造（CSRF）

  预设情况下，Rails包括一个指令码，它包含了一个名为X-CSRF-Token的标头，其安全代码(Token)对应於每个非GET Ajax呼叫。
  当使用另一个函式库进行Ajax呼叫时，有必要将安全代码(Token)加入为函式库中Ajax呼叫的预设标头。
  可於HTML中查看代码(Token)，应为<%=csrf_meta_tags%>对应的<meta name='csrf-token'content='THE-TOKEN'>标签。

  • 弱密码签名
    Ruby gem具有适当的签名机制，但不是必需的，且缺乏对签名金钥的信任链。

  • 函式库

    • Terrapin:用於系统命令。
    • Strong_parameters:避免批次赋值问题。
    • Strong_parameters_rails2:避免批次赋值问题。

  • 参考资料

    • http://guides.rubyonrails.org/security.html
    • http://guides.rubyonrails.org/v3.2.8/security.html
    • https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet

• 避免将用户输入与呼叫合并

  Ruby on Rails支持许多呼叫，这些呼叫可能包含一些潜在漏洞。
  - Eval（"程序范围"）
  - Instance_eval（）
  - Class_eval（）
  - Kernel.exec（"OS范围"）
  - System（"os范围"）
  - Popen
  - open（"os范围"）
  - DRb.start_server（）
  - ls -al（引号执行系统命令）
  - Find_by_sql（）
  - %X（）
  - send（）
  - send（）
  - public_send（）
  - try（）
  - render（）

  • 修正方式
    避免使用未经过滤的用户输入形成系统或Ruby命令。
    如果需要用户输入来通知该命令，则可以做一些过滤来最大程度地减少暴露。
    在将用户输入传递给命令执行功能之前，将用户输入与白名单进行比较是验证输入的有效方法。

    为了使用用户输入执行系统命令，可 使用Terrapin将参数传递给run（）方法的内容进行转义。

  • 风险等级
    高

  • 参考资料

    • https://github.com/thoughtbot/terrapin

• 使用正确的正则表达式(REGEX)字符串符号的开始和结束

  Ruby使用与许多其他语言略有不同的方法来匹配字符串的结尾和开头。
  当使用REGEX验证用户输入时，滥用这些符号可能会导致绕过通过REGEX验证获得恶意输入的可能性。

    #`^`和`$`:匹配每行的开头和结尾，而不是字符串的开头和结尾。
    #`\A`和`\z`:用以代替"^"和" $"。
  

  • 问题范例
    排除无效的URL。

      #正则表达式
      /^https？:\/\/[^\n]+$/i
    

  • 修正方式
    排除无效的URL。

      #正则表达式
      /\Ahttps？:\/\/[^\n]+\z/i
    

  • 风险等级
    高

  • 参考资料

    • http://guides.rubyonrails.org/security.html#regular-expressions

• 确保动态内容已编码

  预设情况下，资料的输出应进行编码来防止跨站点指令码（XSS）。
  Ruby on Rails中却有几种方法可以让开发人员绕过预设的XSS保护。
  XSS可用於执行经过身份验证的用户有权存取的任何操作，包括透过同一身份验证提供程序处理身份验证的其他服务。

  在这里，@user.website值可以以javascript:标记开头，执行其後的所有JavaScript。

    <%=raw @product.name%>
    <%[email protected]_safe%>
    <%=content_tag @product.name%>
    <%=link_to"网址"，@user.website%>
  

  • 修正方式
    这些方法仅应用於信任非用户提供的不包含用户输入内容的内容。

  • 风险等级
    高

  • 参考资料

    • https://www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet#Cross-site_Scripting_.28XSS.29

• 大量赋值的利用

  批量赋值功能在较旧的版本中可能会成为问题，因为它允许攻击者通过操纵传递给模型的new（）方法的杂凑来设置任何模型的属性。
  为避免这种情况，应在全域范围内使用"Strong Parameters"在所有模型中强制将属性列入白名单。
  "Strong Parameters"要求您每次检索参数时都必需指定和允许的参数。
  从安全角度来看，与资料储存区的交互通常是Web应用程序中最敏感的区域之一。
  确保用户不能利用这些交互来提升特权或获得对资料的未经赋值的存取对於整体应用程序安全至关重要。

  预设启用:Strong Parameters

    config.active_record.whitelist_attributes = true
  

  依角色存取的白名单:

    	attr_accessible:name
    	attr_accessible:name，:is_admin，:as =>:admin
  

  • 问题范例
    如果您使用批量赋值建立新使用者，并依靠用户记录来管理存取权限，则有可能成为管理员:

    批量赋值建立新使用者:

      	def signup
      		params[:user]
      		@user = User.new（params [:user]）
      	end
    

  • 修正方式
    启用"Strong Parameters"。

  • 风险等级
    中

  • 参考资料

    • https://github.com/rails/strong_parameters
    • https://github.com/grosser/strong_parameters/tree/rails2
    • http://guides.rubyonrails.org/v3.2.8/security.html#mass-assignment

• 加强HTTPS和严格的传输安全性

  AppSec建议所有Web应用程序在用作Session管理时都强制执行传输加密（HTTPS）并利用严格传输安全性来保护Session cookie。
  严格的传输安全性告诉浏览器仅通过加密的通道存取Web应用程序。
  用户与Web服务器之间的流量的强加密在保护用户的身份验证Session以及与服务器交换的资料方面起着关键作用。

  • 修正方式
    於配置文件中强制设定SSL连接:

      config.force_ssl = true
    

  • 风险等级
    中

• 防止记录敏感讯息

  预设情况下，Rails记录对Web应用程序发出的所有请求。
  但是日志文件可能是一个巨大的安全问题，因为它们可能包含登录凭证，信用卡卡号等。

  记录敏感的用户讯息会使该资料受到威胁的风险更高。这也是GDPR问题。

  • 修正方式
    在设计Rail应用程序时，请确保指定不应记录的请求参数。
    这些应该附加到Rails配置中的过滤参数列表中:

      config.filter_parameters <<:cc_number
    

  • 风险等级
    中

  • 参考资料

    • http://guides.rubyonrails.org/security.html#logging

• 避免禁用deep_munge

  由於Active Record解释参数的方式与Rack解析查询参数的方式相结合，因此可以使用IS NULL where子句发出意外的资料库查询。
  为了解决该安全问题，引入了deep_munge（）方法作为预设情况下保持Rails安全的解决方案。
  启用此参数可避免遭受SQL注入攻击的风险。

  • 修正方式
    请启用deep_munge（）。

  • 风险等级
    中

  • 参考

    • http://guides.rubyonrails.org/security.html#unsafe-query-generation

• 将Rails主金钥储存在环境变量

  Rails将储存一个主要金钥，该金钥生成到版本控制中被忽略的config/master.key文件中。
  但是，Rails还将在ENV["RAILS_MASTER_KEY"]中寻找该键值。

  保护机密的一部分是使它们脱离版本控制。
  AppSec建议使用Infrastructure Engineering的Vault实例进行机密管理。
  另外，从环境变量中储存和检索秘密是更好的选择。

  • 修正方式
    建议从config/master.key文件中删除金钥，并将其放置在生产环境中的RAILS_MASTER_KEY环境变量中。

  • 风险等级
    低

  • 参考资料

    • http://guides.rubyonrails.org/security.html#custom-credentials

• 不允许用户输入确定要渲染的网页

  Rails的render（）方法通过提供要渲染的模板名称来实现动态渲染。
  如果Rails应用程序包含仅限於某些用户角色的网页，则这可能使攻击者能够规避那些存取控制并以较低特权用户身份存取受限制的网页。

  • 修正方式
    避免在某些页面受到限制时使用用户输入来选择要渲染的页面。

  • 风险等级
    低

• Session固定攻击

  Session固定攻击是用於将预先认证Session代码(Token)用作认证後Session代码(Token)的术语。
  换句话说，认证後未设置新的Session代码(Token)。
  如果正在使用基於标头的身份验证，这不是问题。

  一旦知道了浏览器中当前Session代码(Token)的设置，攻击者就可以劫持用户登录的经过身份验证的Session。

  • 修正方式
    用户成功通过身份验证後，请使用reset_session（）函数在其浏览器中设置新的Session cookie。

  • 风险等级
    低

  • 参考资料

    • http://guides.rubyonrails.org/security.html#session-fixation-countermeasures