Session hijacking is a class of attacks where an attacker gets hold of a session identifer of another user. Consequently, he gets access to the web application, because the sessionidentifer serves as temporary login credential. The most popular way of hijacking a session is to steal the session identifer. There are several ways doing this.Most cross-site scripting attacks aim at stealing a user's session identifer.
By default, Rails stores the session identifer in a cookie. However, if one decides to use an URL parameter to keep track of the session identifer, he should be even more aware of the possibilityof session stealing. For example if your web applications contains an external link and a logged in user clicks on it, the target web site can see in its web server logs fromwhich URL (including the session identifer) the user came from.
A countermeasure against session id sniffing could be to encrypt the entire data traffc using SSL. However, if parts of the web site are not encrypted with SSL, such as the login or index page, the cookie will be transmitted nevertheless. To instruct the browser only to send the cookie over encrypted HTTPS and never over normal HTTP, you have to include the following line in the confg/environment.rb file.
ActionController::Base.session_options[:session_secure] = true
Another countermeasure is to save user-specifc properties in the session, verify themevery time a request comes in, and deny access, if the information does not match. Suchproperties could be the remote IP-address or the user agent (i.e. the web browser software's name), though the latter is less user-specifc. When saving the IP-address, you have tobear in mind that there are Internet access provider or large organizations that put their users behind proxies and these might change over the course of a session, so these users willnot be able to use your application or only in a limited way. Also, the attacker could be in the same local network and so both the victim and the attacker have the same external IP address. Although, if these drawbacks do not apply to your users, as it is the case for users of Intranet applications, for example, this will be an appropriate additional protection.However, the best countermeasure currently, is to expire sessions frequently.
Bookmark to
5 responses so far ↓
1 Chris // Apr 12, 2007 at 7:52
Thanks for the tip on securing cookies via HTTPS. I’m curious … are there any side effects for doing this?
2 admin // Apr 12, 2007 at 8:19
even with HTTPS cookies your app is still vulnerable to XSS or other injection, so it is about the transmission, only. If you transmit only static data over HTTP and you don’t need session data for this, this is it.
3 A couple great post about Session Hijacking // Apr 18, 2007 at 11:11
[…] http://www.rorsecurity.info/2007/04/12/session-hijacking/ http://www.rorsecurity.info/2007/04/15/ses… Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages. […]
4 james // Aug 21, 2007 at 2:54
I believe that this config option means that it will only parse the session id over in the http header if the connection is made on port 443 or via SSL/TLS.
Therefore makes most ecomm systems useless, as the product pages/add to cart are not typically under SSL for performance reasons and sometimes people use a hosted payment page with SSL anyway so have no SSL themselves.
Anyway… Another way to secure your site from this is to update your session id on login/logout and heck, perhaps on checkout or something, in PHP this is as simple as session_regenerate_id(), and im not sure in ruby but im sure theres a fantastically simple way of doing it in that to as usual.
5 Heiko // Aug 21, 2007 at 3:07
That’s what it does, the browser sends the cookie only over HTTPS.
Here’s how to do that in Rails:
Session fixation
Leave a Comment