Thursday
Apr122007
Session hijacking
Thursday, April 12, 2007 at 5:37PM 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.
View Printer Friendly Version
Email Article to Friend
Reader Comments (21)
Thanks for the tip on securing cookies via HTTPS. I'm curious ... are there any side effects for doing this?
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.
[...] 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. [...]
Adderall....
rainstorm and the birds fly to and fro and shriek dot Where do they
*
magnificent ruin dot On the morrow they were to part perhaps forever dot
lindentrees on the Rent Tower till gradually the crowd disappeared
*
They had rambled once more together and for the last time over the
I don’t want to wait till the end of Summer :( , I want it now. Who with me?
save your time . ;)
Disney sex toon sex toon. Toon anima sex. Toon sex vids. Disney sex toon....
Weight Loss Reviews. Hoodia effortlessly reduce their caloric intake by 7000 calories each week. Visit: www.healthshop.tv
Would it help at all to create new sessions, copying over the login info (token) from the old session? And therefore allow for more frequently expired sessions without logging out my users?
I may be talking nonsense as I am not too experienced with web-dev.
hello
much interesting found for you on www.rorsecurity.info I got to you from a search engine through a site spam ana while
I ustal after today in life in a network if that write on mail
key mesage for you
link for you
http://thai-sex.yourda4a.info/porn-stars-dvd.html
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.
That's what it does, the browser sends the cookie only over HTTPS.
Here's how to do that in Rails:
c958t
c563t
c177t
c715t
Great site and useful content! Could you leave some opinion about my sites?
[url=http://ownsite.com/b/]My pages[/url]
http://ownsite.com/p/ My pages
the society or, secondly, in manufacturing and preparing that rude produce establish this intercourse universally, and all at once were it pkkqjxvgcf
Greetings, I enjoy your blog. This is a nice site and I wanted to post a note to let you know, good job! Thanks
xiaoxiao123 08 25
Juicy Couture
Omega Watches