Improving Security with URL Rewriting

April 9, 2009 – 3:54 PM

Most web application security experts frown on the practice of passing session or authentication tokens in a URL through the use of URL rewriting. Usually these tokens are passed between the server and the browser through HTTP cookies, but in cases where users configure their browsers to not accept cookies, this is impossible. Some web application frameworks – including ASP.NET – will detect this condition and revert to the cookieless URL rewriting method for passing session tokens. For example, a user who requests the page http://www.contoso.com/welcome.aspx would be redirected to http://www.contoso.com/{SID}/welcome.aspx, where {SID} is that user’s unique session identifier.

Again, most web application security people will tell you that this technique is fraught with peril. It can lead to session hijacking vulnerabilities (a man-in-the-middle sniffs the session identifier out of the URL) as well as session fixation vulnerabilities (an attacker creates his own session and tricks a victim into using it). I once identified enabling cookieless sessions as one of the top ten configuration mistakes made by ASP.NET developers. However, if we make one small change in the way we perform the URL rewriting, it becomes a powerful technique for improving security rather than weakening it.

Instead of rewriting the session id into the URL, we keep the session id in a cookie as usual, but add a second unique token (a “canary” token) into the URL. At the same time, we associate this new canary value with the session id and store it in server session state. Whenever the user makes a request back to the server, the request must include the matching canary or the server will consider the request a forgery. Some diagrams might help explain this a little better.

Source:
http://blogs.msdn.com/sdl/archive/2009/04/09/improving-security-with-url-rewriting.aspx