Rails 3.2.13 was released just a week ago. Since it fixes 4 important security breaches (CVE-2013-1854 for activerecord, CVE-2013-1855 for actionpack, CVE-2013-1856 for activesupport and CVE-2013-1857 for actionpack), you may want to upgrade it asap.
Yet, performance regressions and major bugs has been discovered in this new version of Rails.

What are the risks ?

Upgrading your application to Rails 3.2.13 will make bugs and performance issues popping out.

• action_missing function will be broken
• ActiveRecord chained scopes will cause bugs such as the one GitHub experienced lately
• Assets and views loading time will drastically increase

How to remain safe without upgrading to 3.2.13?

We recommend you to not upgrade to Rails 3.2.13 and to wait for 3.2.14 to be released. But how to do so having in mind the 4 security breaches that still exists ?
Well, that’s simple, first of all, you might not be impacted by all of those issues and second, some monkey patches have been released to help you keep your application secure without upgrading.
So keep calm, create a temporary hotfix branch until 3.2.14 is out and apply the patches you need.

Fixing Symbol DoS vulnerability in Active Record (CVE-2013-1854)

Your application does not use params as a find value for a query? You’re safe!

Impacted code will look like User.where(:name => params[:name]). To fix this issue, you should call to_s method on params used as a find value. Basically, you’ll need to change code that looks like

User.where(:name => params[:name]) 

to:

User.where(:name => params[:name].to_s)

Patch provided by Rails team

Fixing XSS vulnerability in sanitize_css in Action Pack (CVE-2013-1855)

You don’t use sanitize_css method using user input as parameter? You’re safe!

Impacted code will look like sanitize_css(user_input). The following patch will fix the issue:

module HTML 
  class WhiteListSanitizer 
    # Sanitizes a block of css code. Used by #sanitize when it comes across a style attribute 
    def sanitize_css(style) 
      # disallow urls 
      style = style.to_s.gsub(/url\s*\(\s*[^\s)]+?\s*\)\s*/, ' ') 

      # gauntlet 
      if style !~ /\A([:,;#%.\sa-zA-Z0-9!]|\w-\w|\'[\s\w]+\'|\"[\s\w]+\"|\([\d,\s]+\))*\z/ || style !~ /\A(\s*[-\w]+\s*:\s*[^:;]*(;|$)\s*)*\z/ 
        return '' 
      end 

      clean = [] 
      style.scan(/([-\w]+)\s*:\s*([^:;]*)/) do |prop,val| 
        if allowed_css_properties.include?(prop.downcase) 
          clean <<  prop + ': ' + val + ';' 
        elsif shorthand_css_properties.include?(prop.split('-')[0].downcase) 
          unless val.split().any? do |keyword| 
            !allowed_css_keywords.include?(keyword) && 
            keyword !~ /\A(#[0-9a-f]+|rgb\(\d+%?,\d*%?,?\d*%?\)?|\d{0,2}\.?\d{0,2}(cm|em|ex|in|mm|pc|pt|px|%|,|\))?)\z/ 
          end 
          clean << prop + ': ' + val + ';' 
        end 
      end 
    end 
    clean.join(' ') 
  end 
end 

Patch provided by Rails team

Fixing XML Parsing Vulnerability affecting JRuby users (CVE-2013-1856)

Your application does not use JRuby? Your JRuby application does not use the JDOM backend? You’re safe!

To fix this issue, place this code in an application initializer:

ActiveSupport::XmlMini.backend="REXML"

Patch provided by Rails team

Fixing XSS Vulnerability in the sanitize helper (CVE-2013-1857)

Your app doesn’t use sanitize method helper with user input? You’re safe!

To fix this issue, place the following code into a file in your config/initializers folder.

module HTML
  class WhiteListSanitizer
    self.protocol_separator = /:|(&#0*58)|(&#x70)|(&#x0*3a)|(%|%)3A/i

    def contains_bad_protocols?(attr_name, value)
      uri_attributes.include?(attr_name) &&
      (value =~ /(^[^\/:]*):|(&#0*58)|(&#x70)|(&#x0*3a)|(%|%)3A/i &&
      !allowed_protocols.include?(value.split(protocol_separator).first.downcase.strip))
    end
  end
end

Patch provided by Rails team

As announced last week, we are pleased to release today the new features focusing on security.

Remember: since Gemnasium-2.0 we monitor popular packages, looking for security or critical updates. Once something is detected, all impacted versions are tagged accordingly which ends up to a red color on the projects depending on it.

It’s time to put some steroids in this! Let’s review the new features:

Security advisories

To bring you more information on these critical and security updates, Gemnasium now displays advisories right on the package’s page.

Advisories provide useful informations about security issues or critical updates: description, affected versions, fixed versions, available solutions etc…

Advisories are displayed on each affected versions of a package and also on the ones that fix it.

Alerts

But that’s not enough… Keep calm and let the Security Coach tell you what’s wrong with your projects!

Right from your project page you now can check the security and critical advisories affecting your dependencies.

Open alerts just hang here until your project become safe! They are closed automatically when the dependency is updated to a non-affected version.

If your app has been fixed with a patch, a workaround or is simply not affected by the advisory, you can tell Gemnasium it’s okay and just close the alert.

Notifications and reminder

Gemnasium’s Security Coach will warn you immediately when an advisory is created and will remind you every day until the alert is closed (by an update or using the close button). But if you feel bothered by the reminder and still haven’t fixed the issue, you can acknowledge the alert to stop the notifications. This can be done on the project page or directly from your alert email.

To avoid spamming you when you have a lot of affected projects, notifications are grouped by advisory. Here is a sample alert email:

The security reminder takes your notifications settings into account. So you only receive security emails for projects and packages that have notifications enabled and you won’t be notified at all if you have totally disabled notifications in your settings.

Please note that all old alerts have been automatically acknowledged to avoid spamming you. Feel free to reopen them if you want to be reminded.

The notifications and reminder features are included in all plans starting from Bonzaï (see pricing), and also available as trial during the 1st month of registration for Free plans. As an exceptional offer, the security reminder is also available to all existing Free users until March, 31st!

Side notes

Gemnasium is still growing its changelogs base and advocates for a common format. Your opinion is welcome and you can contribute on the Vandamme open source project to help us defining a convention.

As always, we hope you’ll appreciate these new features and your feedback is welcome!

Cheers, Gemnasium Team

This subject is really not very often highlighted in rails security docs, even in the official guide.

We’re often happy with the basic cookie store options :

Anyway, secure websites (like e-commerce sites) must include some more secure options. Cookies have two attributes people usually don’t use :

• Secure : “A server can specify thesecure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.”
• Expires : “Cookies expire, and are therefore not sent by the browser to the server, under any of these conditions: […] An expiration date has been specified, and has passed.”

(Definition taken from Wikipedia)

The last means the session AND the cookie will expire after the given date. It’s generally a good idea to set this option, unless you’re running facebook.com, people won’t spend more than 1 hour on you site per day.

To enable these 2 options, you can use the configuration in config/environment.rb :

You should set the secure option per environment, otherwise your dev environment will fail. To do so, you can add a line in each secure environment :