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.