Java Practices -> Beware of URL rewriting

Beware of URL rewriting

Sessions can be implemented with two underlying mechanisms -- cookies and URL rewriting. URL rewriting involves placing a session id in the URL, as in

http://www.javapractices.com/topic/TopicAction.do;jsessionid=863F3D316?Id=191

According to the Open Web App Security Project, URL rewriting has significant security risks. The general idea is that since the session id appears in the URL, it may be easily seen by third parties:

end users often copy and paste such links without knowing the attached session id compromises their security
server log files usually record the 'Referer' header, which will record session ids in the log

Third-party access to session id's simply means that private user information is wide open to attack. Thus, many argue that URL rewriting is a dangerous practice, and should be avoided. If cookies are used instead, then the session id does not appear in the URL.

It's possible that some web sites may use cookies to track user browsing patterns. As a result, some users turn off cookies in an attempt to protect their privacy. However, given the seriousness of the above security issue, many would argue that turning off cookies is actually much worse for user privacy. That is, the risk of compromising personal data through session hijacking seems to far outweigh concerns about tracking personal browsing patterns.

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

In the case of public web sites, you will need to decide if requiring browsers to keep cookies enabled is acceptable in each case.