5

Hi I have recently read JSP and came across its technologies, mainly session. Under session, I read URL rewriting one of the method that was been done in order to maintain the session with the client. But since the URL rewriting changes the URL with the session ID and it can be visible to the client. Is that not a security issue? Lets say for example, if any one note this session ID apart from the particular user, and can make a bad use of it? Or else there are techniques for preventing these?

Correct me if am wrong.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Ant's
  • 13,545
  • 27
  • 98
  • 148

4 Answers4

8

Certainly this is a security concern. If you quickly take note of the jsessionid value, either from a by someone else mistakenly in public copypasted URL or a in public posted screenshot of some HTTP debugging tool (Firebug) which shows the request/response headers, and the website in question maintains users by a login, then you'll be able to login under the same user by just appending the jsessionid cookie to the URL or the request headers. Quickly, because those sessions expire by default after 30 minutes of inactivity. This is called a session fixation attack.

You can disable URL rewriting altogether so that the jsessionid never appears in the URL. But you're still sensitive to session fixation attacks, some hacker might have installed a HTTP traffic sniffer in a public network or by some trojan/virus, or even used XSS to learn about those cookies. To be clear, this security issue is not specific to JSP, a PHP, ASP or whatever website which maintains the login by a cookiebased session, is as good sensitive to this.

To be really safe with regard to logins, let the login and logged-in traffic go over HTTPS instead of HTTP and make the cookie HTTPS (secure) only.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Well said, but why doesn't this is not specific to JSP? – Ant's May 10 '11 at 03:34
  • 1
    JSP `HttpSession` is backed by a `jsessionid` cookie. PHP `$_SESSION` is backed by a `PHPSESSID` cookie. ASP `Session` is backed by a `ASPSESSIONID` cookie. If you store the logged-in user in the session, it really doesn't matter what language is more sensitive or not. The JSP `jsessionid` is just more in the news because some Java servers/frameworks have by default URL rewriting turned on. – BalusC May 10 '11 at 03:36
  • Oh ok, i have misunderstood what you have said, thanks for the reply – Ant's May 10 '11 at 03:38
  • What describe as session fixation is actually called session hijacking. Hijacking means the attacker uses the victim's session id. Session fixation means that the attacker makes the victim use the attacker's prepared session, e.g. by letting them request a link that contains the attacker's session id. – Wolfgang Aug 25 '13 at 10:17
  • can somebody please throw some more light on "You can disable URL rewriting altogether so that the jsessionid never appears in the URL" – Vipin Verma Nov 06 '13 at 15:28
  • @vipin8169: set `COOKIE` in `web.xml`. – BalusC Nov 06 '13 at 15:37
2

URL rewriting of session cookies is discouraged in most (if not all) security circles. OWASP ASVS explicitly discourages its use as it results in exposure of the session identifiers via an insecure medium.

When URL rewriting of session cookies is enabled, the URL could be transmitted (with the session identifier) to other sites, resulting in disclosure of the session identifier via the HTTP Referrer header. In fact, a simple request by a browser to a resource located on another domain will result in possible hijacking (via a Man-In-The-Middle attack) or fixation of the session; this is as good as a Cross Site Scripting vulnerability in the site.

On a different note, additional protection mechanisms like the HttpOnly and Secure-Cookie flags introduced into various browsers for protecting the session cookie in different ways, can no longer be used when URL rewriting of cookies is performed by a site.

Vineet Reynolds
  • 76,006
  • 17
  • 150
  • 174
0

I believe you're referring to cookieless sessions. Although I have seen it referred to as 'url rewriting' in Java circles.

There are some extra session hijacking concerns (and they apply across all web development frameworks that support cookieless sessions--not just JSP). But session hijacking is possible even with cookies.

Here's a pretty good in-depth article on MSDN about cookieless sessions and the risks/benefits. Again, these are all platform agnostic.

http://msdn.microsoft.com/en-us/library/aa479314.aspx (toward the bottom)

Brian Rosamilia
  • 1,448
  • 14
  • 24
0

This is what I came accross checking the OWASP specifications for URL rewriting and it Exposing session information in the URL is a growing security risk (from place 7 in 2007 to place 2 in 2013 on the OWASP Top 10 List).

Options for managing URL rewriting include :

disabling them at the server level. disabling them at the application level. An attractive option is a Servlet filter. The filter wraps the response object with an alternate version, which changes response.encodeURL(String) and related methods into no-operations. (The WEB4J tool includes such a filter.)

Dev_panda
  • 21
  • 5