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=191According 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
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.)
See Also :
Would you use this technique?