Url Rewriting - Does that cause a security issue?

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 sessio开发者_JS百科n 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.

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.

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.

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)

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