Ruby on Rails Cheatsheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:22:09Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T14:05:02Z

Migration to GitHub

Show changes

ZaurMolotnikov: Improved and updated XSS section.

2018-01-18T12:04:09Z

Improved and updated XSS section.

ZaurMolotnikov: Forcing TLS when using authentication.

2017-12-07T12:39:35Z

Forcing TLS when using authentication.

ZaurMolotnikov: Syntax highlights added

2017-12-06T16:37:40Z

Syntax highlights added

ZaurMolotnikov: Syntax highlights added

2017-12-06T16:35:20Z

Syntax highlights added

ZaurMolotnikov: Syntax highlights added

2017-12-06T16:33:06Z

Syntax highlights added

ZaurMolotnikov: Syntax highlights added

2017-12-06T16:31:07Z

Syntax highlights added

ZaurMolotnikov: Corrected a mistake in the highlight

2017-12-06T16:26:03Z

Corrected a mistake in the highlight

ZaurMolotnikov: Syntax highlights added

2017-12-06T16:25:12Z

Syntax highlights added

← Older revision		Revision as of 14:22, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Ruby_on_Rails_Cheatsheet.md Ruby on Rails Cheatsheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheatsheet.html Ruby on Rails Cheatsheet] to see the latest version of the cheat sheet.

@@ Line 60: / Line 60: @@
 == Cross-site Scripting (XSS) ==
-By default, in Rails 3.0 protection against XSS comes as the default behavior.  When string data is shown in views, it is escaped prior to being sent back to the browser.  This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing.  In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).
+By default, in Rails 3.0 and up protection against XSS comes as the default behavior.  When string data is shown in views, it is escaped prior to being sent back to the browser.  This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing.  In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).
      <syntaxhighlight lang="ruby" line='line'>
-     <%= raw @product.name %>
+     <%= raw @product.name %>  #  - Wrong! Older rails versions, do not do this!
-     <%= @product.name.html_safe %>       These are examples of how NOT to do it!
+     <%= @product.name.html_safe %>  # - Wrong! Newer rails versions, do not do this!
-     <%= content_tag @product.name %>
+     <%= content_tag @product.name %> # - Wrong! Newer rails versions, do not do this!
      </syntaxhighlight>
-Unfortunately, any field that uses raw like this will be a potential XSS target.  Note that there are also widespread misunderstandings about html_safe.  [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail.  Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.
+Unfortunately, any field that uses raw, html_safe, content_tag or similar like this will be a potential XSS target.  Note that there are also widespread misunderstandings about html_safe.  [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail.  Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.
 If you must accept HTML content from users, consider a markup language for rich text in an application (Examples include:  markdown and textile) and disallow HTML tags. This helps ensures that the input accepted doesn’t include HTML content that could be malicious. If you cannot restrict your users from entering HTML, consider implementing content security policy to disallow the execution of any javascript. And finally, consider using the #sanitize method that let's you whitelist allowed tags. Be careful, this method has been shown to be flawed numerous times and will never be a complete solution.
-An often overlooked XSS attack vector is the href value of a link:
+An often overlooked XSS attack vector for older versions of rails is the href value of a link:
      <syntaxhighlight lang="ruby" line='line'>
@@ Line 83: / Line 91: @@
      <a href=”javascript:alert(‘Haxored’)”>Personal Website</a>
      </syntaxhighlight>
 OWASP provides more general information about XSS in a top level page: [[Cross-site Scripting (XSS)]].

← Older revision		Revision as of 12:39, 7 December 2017
Line 100:		Line 100:
	== Authentication ==		== Authentication ==

		+	As with all sensitive data, start securing your authentication with enabling TLS in your configuration:
		+
		+	<syntaxhighlight lang="ruby" line='line'>
		+	# config/environments/production.rb
		+	# Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies
		+	config.force_ssl = true
		+	</syntaxhighlight>
		+
		+	Uncomment the line 3 as above in your configuration.
		+
	Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication.		Generally speaking, Rails does not provide authentication by itself. However, most developers using Rails leverage libraries such as Devise or AuthLogic to provide authentication.

@@ Line 260: / Line 260: @@
 The most basic, but restrictive protection is to use the :only_path option. Setting this to true will essentially strip out any host information.  However, the :only_path option must be part of the first argument. If the first argument is not a hash table, then there is no way to pass in this option.  In the absence of a custom helper or whitelist, this is one approach that can work:
-−
    begin
      if path = URI.parse(params[:url]).path
@@ Line 268: / Line 269: @@
      redirect_to '/'
    end
 If matching user input against a list of approved sites or TLDs against regular expression is a must, it makes sense to leverage a library such as URI.parse() to obtain the host and then take the host value and match it against regular expression patterns. Those regular expressions must, at a minimum, have anchors or there is a greater chance of an attacker bypassing the validation routine.
@@ Line 273: / Line 275: @@
 Example:
      require ‘uri’
      host = URI.parse(“#{params[:url]}”).host
@@ Line 280: / Line 283: @@
          # you could also check the host value against a whitelist
      end
 Also blind redirecting to user input parameter can lead to XSS. Example:
      redirect_to params[:to]
      http://example.com/redirect?to[status]=200&to[protocol]=javascript:alert(0)//
@@ Line 288: / Line 298: @@
 The obvious fix for this type of vulnerability is to restrict to specific Top-Level Domains (TLDs), statically define specific sites, or map a key to it’s value. Example:
      ACCEPTABLE_URLS = {
          ‘our_app_1’ => “https://www.example_commerce_site.com/checkout”,
          ‘our_app_2’ => “https://www.example_user_site.com/change_settings”
+     }
 http://www.example.com/redirect?url=our_app_1
     def redirect
         url = ACCEPTABLE_URLS[“#{params[:url]}”]
         redirect_to url if url
     end
 There is a more general OWASP resource about [[Unvalidated Redirects and Forwards Cheat Sheet|unvalidated redirects and forwards]].

@@ Line 231: / Line 231: @@
 When working with a model, the attributes on the model will not be accessible to forms being posted unless a programmer explicitly indicates that:
      class Project < ActiveRecord::Base
          attr_accessible :name, :admin
      end
 With the admin attribute accessible based on the example above, the following could work:
@@ Line 241: / Line 243: @@
 Review accessible attributes to ensure that they should be accessible.  If you are working in Rails < 3.2.3 you should ensure that your attributes are whitelisted with the following:
      config.active_record.whitelist_attributes = true
 In Rails 4.0 strong parameters will be the recommended approach for handling attribute visibility. It is also possible to use the strong_parameters gem with Rails 3.x, and the strong_parameters_rails2 gem for Rails 2.3.x applications.

@@ Line 205: / Line 205: @@
 Ruby on Rails has specific, built in support for CSRF tokens.  To enable it, or ensure that it is enabled, find the base ApplicationController and look for a directive such as the following:
      class ApplicationController < ActionController::Base
          protect_from_forgery
 Note that the syntax for this type of control includes a way to add exceptions.  Exceptions may be useful for API’s or other reasons - but should be reviewed and consciously included.  In the example below, the Rails ProjectController will not provide CSRF protection for the show method.
     class ProjectController < ApplicationController
         protect_from_forgery :except => :show
 Also note that by default Rails does not provide CSRF protection for any HTTP GET

@@ Line 21: / Line 21: @@
      Kernel.exec("os command here")
      open("| os command here")
 While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application.  Usually, its just a bad idea.  If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.  The Ruby Security Reviewer's Guide has a  [http://code.google.com/p/ruby-security/wiki/Guide#Good_ol%27_shell_injection section on injection]  and there are a number of OWASP references for it, starting at the top:  [[Command Injection]].
@@ Line 30: / Line 31: @@
 Here is an example (Rails 2.X style):
      @projects = Project.find(:all, :conditions => “name like #{params[:name]}”)
 A Rails 3.X example:
      name = params[:name]
      @projects = Project.where(“name like ‘“ + name + “‘“);
 In both of these cases, the statement is injectable because the name parameter is not escaped.
@@ Line 41: / Line 46: @@
 Here is the idiom for building this kind of statement:
      @projects = Project.find(:all, :conditions => [ “name like ?”, “#{params[:name]}”] )
 An AREL based solution:
      @projects = Project.where("name like ?", "%#{params[:name]}%")
 Use caution not to build SQL statements based on user controlled input.  A list of more realistic and detailed examples is here: [http://rails-sqli.org rails-sqli.org].  OWASP has extensive information about [[SQL Injection]].
@@ Line 53: / Line 62: @@
 By default, in Rails 3.0 protection against XSS comes as the default behavior.  When string data is shown in views, it is escaped prior to being sent back to the browser.  This goes a long way, but there are common cases where developers bypass this protection - for example to enable rich text editing.  In the event that you want to pass variables to the front end with tags intact, it is tempting to do the following in your .erb file (ruby markup).
      <%= raw @product.name %>
      <%= @product.name.html_safe %>       These are examples of how NOT to do it!
      <%= content_tag @product.name %>
 Unfortunately, any field that uses raw like this will be a potential XSS target.  Note that there are also widespread misunderstandings about html_safe.  [http://stackoverflow.com/questions/4251284/raw-vs-html-safe-vs-h-to-unescape-html This writeup] describes the underlying SafeBuffer mechanism in detail.  Other tags that change the way strings are prepared for output can introduce similar issues, including content_tag.
@@ Line 63: / Line 74: @@
 An often overlooked XSS attack vector is the href value of a link:
      <%= link_to “Personal Website”, @user.website %>
 If @user.website contains a link that starts with “javascript:”, the content will execute when a user clicks the generated link:
      <a href=”javascript:alert(‘Haxored’)”>Personal Website</a>
 OWASP provides more general information about XSS in a top level page: [[Cross-site Scripting (XSS)]].
@@ Line 77: / Line 92: @@
 The best practice is to use a database based session, which thankfully is very easy with Rails:
      Project::Application.config.session_store :active_record_store
 There is an OWASP [[Session Management Cheat Sheet]].

@@ Line 15: / Line 15: @@
 Ruby offers a function called “eval” which will dynamically build new Ruby code based on Strings.  It also has a number of ways to call system commands.
-   <syntaxhighlight lang="ruby" line='line'>
+    <syntaxhighlight lang="ruby" line='line'>
-   eval("ruby code here")
+    eval("ruby code here")
-   System("os command here")
+    System("os command here")
-   `ls -al /`   (backticks contain os command)
+    `ls -al /`   (backticks contain os command)
-   Kernel.exec("os command here")
+    Kernel.exec("os command here")
-   open("| os command here")
+    open("| os command here")
 While the power of these commands is quite useful, extreme care should be taken when using them in a Rails based application.  Usually, its just a bad idea.  If need be, a whitelist of possible values should be used and any input should be validated as thoroughly as possible.  The Ruby Security Reviewer's Guide has a  [http://code.google.com/p/ruby-security/wiki/Guide#Good_ol%27_shell_injection section on injection]  and there are a number of OWASP references for it, starting at the top:  [[Command Injection]].