Comments on: URL-based session is insecure and so is JavaBlogs.com http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/ no buzzwords allowed Wed, 10 Mar 2010 17:47:15 -0500 http://wordpress.org/?v=2.9 hourly 1 By: KT http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1801 KT Fri, 19 Sep 2008 11:56:51 +0000 http://dow.ngra.de/?p=247#comment-1801 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 <a href="http://www.codinghorror.com/blog/archives/001167.html" rel="nofollow">HttpOnly attribute</a>. 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.

]]> By: Toomas Römer http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1766 Toomas Römer Wed, 17 Sep 2008 12:07:30 +0000 http://dow.ngra.de/?p=247#comment-1766 I guess the idea was that 3rd party JavaScript scripts can only access their own domain cookies. I guess the idea was that 3rd party JavaScript scripts can only access their own domain cookies.

]]> By: Joerg http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1756 Joerg Tue, 16 Sep 2008 09:47:27 +0000 http://dow.ngra.de/?p=247#comment-1756 You write that cookies cannot be accessed by JavaScript. What about the cookie property in JavaScript document objects ()? Am I missing something? You write that cookies cannot be accessed by JavaScript. What about the cookie property in JavaScript document objects ()? Am I missing something?

]]> By: Toomas Römer http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1487 Toomas Römer Wed, 03 Sep 2008 13:55:00 +0000 http://dow.ngra.de/?p=247#comment-1487 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. 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.

]]> By: Stefan http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1481 Stefan Wed, 03 Sep 2008 07:07:13 +0000 http://dow.ngra.de/?p=247#comment-1481 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. 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.

]]> By: Willie Wheeler http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1479 Willie Wheeler Wed, 03 Sep 2008 06:36:21 +0000 http://dow.ngra.de/?p=247#comment-1479 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.) 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.)

]]> By: Mike http://dow.ngra.de/2008/09/02/url-based-session-is-insecure-and-so-is-javablogscom/comment-page-1/#comment-1469 Mike Wed, 03 Sep 2008 02:49:05 +0000 http://dow.ngra.de/?p=247#comment-1469 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!!! ;) 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!!! ;)

]]>