Intrepidus Group

Owning Rails 2.0 Cookies at OWASP

Posted: November 14, 2007 – 11:37 am | Author: | Filed under: Conferences, Web Apps

Death to Bad Cookies

If you’re out at the OWASP AppSec conference in San Jose this week, we invite you to come hear a presentation about Ruby on Rails security. We’ll mostly be covering how Rails holds up to standard web attacks (SQL Injection, Session Riding, XSS, and on down the list), but also adding in a little deeper dive into the default Rails 2.0 session storage.

The Rails framework is definitely doing some security features very well, but when the final 2.0 version comes out later this year, session storage is not going to be one of them. The new default Rails configuration will actually be storing server side session information in client side cookies. (You read that correctly….) The server side session information is going to be pushed down and stored on the client side web browser’s cookie cache. This new rails session cookie value will consist of two items. The first being a dump of the session object that has been Base64 encoded and then URL encoded. Notice the word encoded not encrypted.

You will be able decode and view all the data in your session object as quickly as you can copy and paste and click. The only thing preventing you from changing that data and resubmitting your “is_admin=true” session hack will be the second part of the cookie value. This will be a hash of the original session value along with the secret server side password (the default hashing algorithm will be SHA1). Do you see where this is going? You will be able to locally brute force the hash to uncover the secret, then put anything you want into your server side session object.

I’ll be posting some code later this week to demonstrate, but everything you need is already in the “cookie_store.rb” file if you’ve downloaded the Rails 2.0 Release Candidate. If you’re using edge rails or building a rails 2.0 application, I would strongly recommend using one of the other session storage choices.


Update: See the “Part II” post for the BustRailsCookie script.

Both comments and trackbacks are currently closed.


  1. Posted November 15, 2007 at 10:58 am | Permalink

    Great find Corey! Maybe it’s not too late for this to be reconsidered.

  2. Posted November 20, 2007 at 5:52 pm | Permalink

    Please see my comment on Part II debunking the claim of brute-force attack.

  3. Posted November 21, 2007 at 12:46 am | Permalink

    Sorry, updated the link for “cookie_store.rb” which did take you to an older version of the file. Brute forcing the HMAC is still possible. I’m sure there are cases where this type of session storage would make sense, but from a security stand point, it makes me nervous that this will be the default storage option.

One Trackback

  1. By PhishMe » Owning Rails 2.0 Cookies at OWASP: Part II on November 19, 2007 at 2:05 pm

    [...] OWASP conference proved to be a great ground to bring up this topic of the proposed Rails 2.0 cookie storage [...]


This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24799 items have been purified.