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.
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.