URL Session Tokens easily compromised - Security Series #6.4

I have said on several occasions that catering to users who insist on disabling cookies is a bad idea. I have blogged a couple times on the reasons.

So why am I suddenly bringing this topic up again? Well I recently read (I cannot recall where, it was probably on the OWASP site) about a way that session tokens in URLs can be easily compromised. I am a little embarrassed that I never realized that this vulnerability existed before. It is pretty simple.

The vulnerability in this case is the web browser's behavior of sending a CGI variable called REFERER or HTTP_REFERER onto the page that the request was directed from. So if I click on a link on index.cfm that takes me to test.cfm then in the CGI scope of test.cfm will be a variable called HTTP_REFERER.


So let's consider a hypothetical situation. Let's say we run some sort of a social networking site where users can log in, post information to their own public profile page, and comment on other users' profile pages. Typical social networking type stuff. Sound like fun? Meh. Anyway, our site has become very popular with the young people ;) and therefore has become a target for vandalism and phishers and other nefarious types.

One of the primary goals of these hackers is to compromise user accounts. One method for doing this is through session hijacking. To accomplish a session hijacking, the hacker needs to compromise the session token of the victim user.

We will call our social networking site http://social.12robots.com.

Now let's say that one of our users is little Sissy Huffinstuff from Dearborn, MI. Little Sissy's public profile page is located at http://social.12robots.com/sissy/. Now little Sissy thinks that she is a savvy internet user, so she has cookies disabled "for security". The developers at social.12robots.com want to accommodate users that have cookies disabled (because they don't know better) so for those users, they pass the session token information in the URL.

A hacker realizes that social.12robots.com has this functionality set up for users without cookies, so the hackers writes a script that posts the following as a comment to as many public profile pages as he can.


Wow, your profile page is awesome. And I love your picture. You're gorgeous. Have you considered professional modeling? I am an agent, checkout <a href="http://hackersite.someotherdomain.com/hacked.cfm">my site</a>.

Now little sissy is a 13-year-old girl who will click on just about anything. She looks at the link and decides it is probably just a spammer, but what is the harm in clicking on the link and checking to make sure it is not a legit site?

So she clicks on the link and sees that it is just a spammer site with a bunch of ads. So she closes her browser and moves on. Does she have any idea that she just sent her session token information to a hacker site? No, she doesn't.

Meanwhile, over on the hacker site, the hackers is logging traffic and just received the following incoming request.



Notice that the HTTP_REFERER variable contains the URL for the site that the request came from, INCLUDING valid session information.

The hacker can now use that information to hijack little Sissy's session and impersonate her at social.12robots.com.

It is the browser that sends the REFERER information, so there is nothing you can do on the server side to prevent this from happening.

Putting session credentials in the URL string is just a bad idea. Require your users to use cookies.

It also does not matter whether you are using CF session management or JEE session management. This will happen with either one.

Technically it would be safer to use an SSL connection as well. When using SSL most browsers will not send the HTTP_REFERER information for this very reason. If you performed this same test on an SSL connection the HTTP_REFERER variable would show up as [empty string]. But again, this is handled by the browser, over which we have no control, so do not count on that.

Comments
Ben Nadel's Gravatar Really good point. I've never considered the use of the Referer value to gather security information.

But seriously, if you *want* to experience the web, you *need* cookies and javascript... 'nuff said.
# Posted By Ben Nadel | 12/18/09 10:33 AM
Ed's Gravatar That's a problem indeed. So, i probably would create for example a special session variable to store user IP and on each request would check check if it's the right one or.. what the heck.. would not allow using the site with cookies/JS disabled :D
# Posted By Ed | 12/18/09 11:34 AM
Brad Wood's Gravatar Nice, detailed post. I had never thought about the cgi referrer giving away security tokens from the URL before-- that is a very good point. I am glad to hear that SSL referrers are not sent.
The problem with cookies even is that they are still vulnerable to man-in-the-middle attacks without SSL.
# Posted By Brad Wood | 12/18/09 11:38 AM
Brad Wood's Gravatar @Ed: The problem with IP address is that it can change if the user is using any sort of Web Proxy (like AOL). Another problem is that many corporations have networks with two external gateways-- one for SSL and one for regular traffic. If your user goes from an HTTP to an HTTPS page on your site, their IP address can change because their internal network routes them to the internet out a different gateway. The latter problem also makes it really hard for load balancers that don't support SSL offloading.
# Posted By Brad Wood | 12/18/09 11:41 AM
Ed's Gravatar @Brad: agreed
# Posted By Ed | 12/18/09 11:46 AM
Jason Dean's Gravatar @All, thanks for the comments and great discussions.

@Ben I agree the web is best with cookies and JS. I still understand those that restrict JS to a white list of sites though.

@Ed, I have thought of doing exactly that numerous times, but I do not know how much it would affect users as described by Brad.

@Brad, yes, cookies can still be intercepted or even sniffed out of the air if not protected by SSL. So the best combinations for session management is SSL + Session Cookies.
# Posted By Jason Dean | 12/18/09 12:01 PM
Steve Bryant's Gravatar Wow. That is really obvious, but I had never thought of it before (I love that stuff!).
# Posted By Steve Bryant | 12/18/09 1:37 PM
Jason Dean's Gravatar @Steve

iknorite?!
# Posted By Jason Dean | 12/18/09 2:32 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner