URL-based session is insecure and so is JavaBlogs.com
Written by Jevgeni Kabanov on September 2, 2008 – 6:17 pmThere 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: java, security, web
Posted in creative | 7 Comments »
7 Comments to “URL-based session is insecure and so is JavaBlogs.com”
Leave a Comment
Additional comments powered by BackType
September 3rd, 2008 at 5:49 am
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!!! ;)
September 3rd, 2008 at 9:36 am
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.)
September 3rd, 2008 at 10:07 am
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.
September 3rd, 2008 at 4:55 pm
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.
September 16th, 2008 at 12:47 pm
You write that cookies cannot be accessed by JavaScript. What about the cookie property in JavaScript document objects ()? Am I missing something?
September 17th, 2008 at 3:07 pm
I guess the idea was that 3rd party JavaScript scripts can only access their own domain cookies.
September 19th, 2008 at 2:56 pm
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.