#356 Dangers of Session Hijacking
Jun 08, 2012 | 6 minutes | Security
If a user's authentication cookie is sent over an insecure connection it is vulnerable to session hijacking, or more specifically, sidejacking. Learn how this is done, and how you can prevent it.
- Download:
- source code
- mp4
- m4v
- webm
- ogv
Thanks Ryan.
What are the benefits of keeping part of your site http, once you have gone through the trouble of setting up a ssl certificate? Is there really that significant of a performance hit in using https?
Except for performance changes, consider user experience. Say some users have no need to login to your site, they just want to see what's there. Putting these users on https might just scare them; why is the connection secure while the user isn't doing anything that should be secured? Depending on your audience, this might be scary.
Jasper, I might look at this the opposite way: hey, this site is doing something good!
Good one
Well, there's caching considerations. With https, a user can't take advantage of any caching between the web server and client. There's also extra negotiation between the client and server to setup the connection. For those of us privileged enough to be on a satellite connection, it kills the speed. But even for those on a normal connection it can slow it down.
Timothy -- not sure what you mean regarding caching. This SO thread suggests it's not an issue (http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https).
I am, however totally sure about your issue with satellite internet. It makes you pine for the days of 28.8 modems :-) To be sure, the additional negotiation costs of SSL would become more evident with a really slow connection.
For most users, however, I would bet that slowness is trivial compared to some of the sloppy sites, shared servers, and other bad programming and hosting practices that are so prevalent. Seems to me the Rails community should be leading the way in the good practice of good, strong security, even if there's a minor cost.
There are sometimes problems with some browsers and mixed-content warnings.
For instance, I just finished a site where the client wanted a Mailchimp signup form in the footer of their site. If the form was submitted as secure, it would not redirect to mailchimp correctly. I couldn't leave the form unencrypted because I would get a mixed-content warning from IE.
Right, but most client-facing tools, like Mailchimp, should offer http as well.
Thanks guys for the discussion. I also found this good conversion on SO.
My take away is (at least for me), all or nothing seems the best way to go.
Hi dear Ryan
thanks for the great episode,
Q: if i am using devise for authentication.. how can i set the secure cookie in a way that works with devise?
thanks again
Joe
It really depends on what your placing in the cookie before you decide to secure it. The simple solution would be to encrypt the cookie via bcryt. But its never a good idea to place sensitive data on the client side. Your cookie should really track the user session to query your database securely.
Device, and probably most other Rails authentication solutions, uses Rails built in sessions. To make the Rails session cookie secure in production add the following to the 'Application.config.session_store' setting in 'session_store.rb':
secure: Rails.env == 'production'
Also, if you are using Rememberable, you should have the following setting in 'devise.rb':
config.rememberable_options = {:secure => Rails.env == 'production'}
Note that even with 'config.force_ssl = true' the cookie will be sent in the clear in the first request if someone chooses to access to site without https, so to be secure you should always use secure cookies. It's also a good idea to set the session cookie to HttpOnly to avoid cross site scripting.
+1 for HttpOnly
Thanks again to Ryan.
I've put up a quick post on how to use this approach for warden.
http://fullware.net/prevent-rails-session-hijack-in-warden/
-Doug
www.fullware.net
Thanks!
BTW, http://fullware.net/prevent-rails-session-hijack-in-warden/ gives 404 error.
So I just want to clarify: If all connections are https and everything is using the built in sessions, do I need to set a secure cookie to be safe? or will that just be happening automatically?
You only need to do the secure cookie thing if you don't want to process all request over https
Thanks for this episode. I never was really aware of this issue.
However, I tried to reproduce the steps in my local network using a Rails app that was already deployed, and the cookies didn't appear anywhere when using tcpdump.
I tested it using my wi-fi network, and 2 different machines (mine and another). When I tried to login using the other machine, none of that info appeared in tcpdump.
I'm using Devise for the authentication.
When I tested it in my local machine, then I could reproduce the vulnerability and see all the cookie information.
Am I missing something? By what I understood, shouldn't I be able to see it when in my local network (and not only localhost)?
If your wifi is secured then your traffic shouldn't ever hit another wifi adapter in order to be tcpdumped. Try it in an open wifi hotspot?
I made my wi-fi public when I tested.
Can it have something to do with OS (I'm on Lion)? I'm not a big understander about networks, but with the wi-fi public shouldn't I see it?
Of course, when doing from my computer I'm able to see that cookie session info, but even that way, when using cURL, I was not logged in. It just redirected me back to the sign_in path.
Any ideas of what could be wrong? I'm just following the same steps.
Is there any reason why you are prefixing the secure cookie with a string and simply not using the user id?
A comprehensive talk on Rails Security in RailsConf 2012
Are there any solutions for integration testing to verify that secure cookies work as I expect?
the funny thing is browser and server are setting up secure keys during public negotiation, so hijacker just needs to listen from the begining of the session - he will have all the keys to see HTTPS traffic
No, they won't. They will have something encrypted. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
In Rails 4 the cookies are secure by default when you use force_ssl in your application configuration. https://github.com/rails/rails/commit/d6933a1e9fdce873e5540813f4d44d313b6d363d
Just FYI there's a typo in the destroy method
cookies.delete[:secure_user_id] should be cookies.delete(:secure_user_id)
[Check Support]