URL-based session is insecure and so is JavaBlogs.com

There are two main ways to associate a session state with a user — session cookies and session URL parameters. However for public sites there may be some risks for the URL-based approach.

Cookies are saved on the computer and are only ever sent in requests to the domain that has saved them. They have always been a focus of security attacks and thus they are pretty well protected. E.g. they cannot be accessed by the included third-party JavaScripts, which is important considering the current proliferation of web widgets.

On the other hands URLs are definitely accessible to the third-party scripts. What’s even worse, is that the browser will send the URL of the previous page as Referrer, when you click a link to go to the third-party site. Since most web servers will log the Referrer the owner of that site can access the logged-in user session as long as it’s live and possibly access private user data.

We hit this issue, when watching the statistics for ZeroTurnaround and clicking on a referrer link to JavaBlogs.com, which uses URL-based sessions. To our surprise we could access the logged in user data. Of course on JavaBlogs there’s not really that much data to access, but on another site this could be a serious issue.

For all I know this issue could be a very old and well-known one, but I never heard of it and apparently neither have JavaBlogs owners. If you’re making a public site make sure to keep this in mind.

Tags: , ,

This entry was posted on Tuesday, September 2nd, 2008 at 6:17 pm by Jevgeni Kabanov and is filed under creative. You can follow any comments to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.

  • Mike

    Its true, but if the users have cookies turned off its the only way to go. For instance Weblogic always uses URL based session id on the first connection, but if it gets the cookie back it discontinues the URL rewrite….drives search engine crawlers nuts!!! ;)

  • http://springinpractice.wordpress.com Willie Wheeler

    Good post. Another thing to be careful about where URL-based session IDs are concerned is something called session fixation. The idea is that the attacker posts a link with a JSESSIONID (talking about Java here) to a forum, a comment, or some other public location. When unsuspecting users click on that link, the default behavior of the servlet container (or at least some servlet containers–I’m not sure if this is mandated by the spec of if it’s container-specific) is to create a session with that ID if one doesn’t already exist. The attacker can check the site from time to time to try to hijack sessions since the attacker knows the session ID. (Sites can defend against this by generating a new JSESSIONID if the user passes one in that doesn’t already exist on the server.)

  • http://www.molindo.at/ Stefan

    An oldie but a goodie ;) There are two countermeasures I can think of:

    - Open external links using a special “hop page”, i.e. don’t like to http://example.org/ directly, use a redirect from a dedicated page, e.g. http://www.example.com/goto?http://www.example.org/ – and make sure not to include the session ID ;)

    - Attach a session to an IP and/or other client specifics (User-Agent or Accept-* HTTP headers come to mind) – this reduces the risk to some degree.

  • Toomas Römer

    One solution to make it more secure is to tie the identifier with some other properties, IP or User-Agent. This isn’t bulletproof but definitely will not let strangers hijack sessions by accident.

  • Joerg

    You write that cookies cannot be accessed by JavaScript. What about the cookie property in JavaScript document objects ()? Am I missing something?

  • Toomas Römer

    I guess the idea was that 3rd party JavaScript scripts can only access their own domain cookies.

  • KT

    You are mistaken about cookie protection.
    The same-origin policy is not really working for scripts included using the <script src=…> tag and stealing cookies in a mashup is not that complicated, really. The only real cookie-protecting solution currently is the HttpOnly attribute.