Improving Security with URL Rewriting

Improving Security with URL Rewriting

  • Comments 10

Hi everyone, Bryan here.

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.

clip_image002

In step one, I make an initial request for a page on www.contoso.com. The Contoso server creates a new session id for me and stores it in the response cookie. The server also creates a new canary value, stores it with the session id in its server-side session state, and writes it into the URL.

clip_image004

In step two, I request a new page. The browser automatically includes the session cookie and the canary value in the request. Before the server processes the request, it checks to ensure that the canary value is present and that it matches its own stored value. The check succeeds, and the server processes the request.

This technique not only helps to prevent the session fixation vulnerability I talked about earlier, but also these dangerous vulns:

· Cross-Site Request Forgery

· Open-redirect phishing

· Some forms of Cross-Site Scripting (XSS)

In the cases of open-redirect phishing and XSS, the canary rewriting technique does not actually fix the vulnerabilities, but it does limit their exploitability. These types of vulns are usually exploited through email: the attacker crafts a malicious hyperlink and then sends it out to potential victims. However, since an attacker cannot include a corresponding cookie value to match the text in the hyperlink (and thus the session id would not match any inserted canary value) the server would reject the request.

For example, let’s say that there is an XSS vulnerability on contoso.com, and the evil hacker Michael tries to exploit it by sending me a malicious hyperlink. Since Michael cannot know ahead of time what my canary token is, even if I do click through the link – which is unlikely, given that I know better than to follow URLs that Michael sends me – the server will still block the request since the tokens won’t match.

clip_image006

There are definitely shortcomings with this technique. One unfortunate side effect of preventing attackers from emailing malicious links is that legitimate users are similarly prevented from emailing benign links, or even from bookmarking links for future access. Also, this defense does nothing to prevent session hijacking through man-in-the-middle attacks. Given these shortcomings, I definitely would not consider using URL rewriting as my only defense against XSS/XSRF/etc, but I think it could make sense as a defense-in-depth measure for sites with high security assurance needs.

If you’re interested in reading more about this idea, I explain it in further detail in the Security Briefs column of the March 2009 issue of MSDN Magazine. I also discuss alternative methods, including a method for implementing a similar defense for stateless applications such as web services. I’ve included C# source code so you can use these defenses in your own ASP.NET applications.

(bryansul standard disclaimer: The methods and techniques discussed in this article should not be construed as official SDL requirements. They are simply ideas that we’re developing to help you create more secure software. If you have any feedback, we’d be happy to hear it.)

Comments
  • PingBack from http://microsoft-sharepoint.simplynetdev.com/improving-security-with-url-rewriting/

  • Przekazywanie identyfikatorów sesji w URL jest ZŁE (mówiłem o tym w prezentacji o zarządzaniu sesją na spotkaniu OWASP). Sama koncepcja umieszczenia w URL dodatkowej unikalnej informacji już zła nie jest, oczywiście zależy do czego będzie ona w

  • I recently released an HTTP Module for IIS that does this on-the-fly for ASP.NET applications (http://www.gdssecurity.com/l/spf/).  It also tracks all GET and POST variables to prevent them from tampering.  You can see a live demo of it at http://trade-spf.gdsdemo.com/.  

  • Interesting idea, but I can't imagine there are very many useful sites out there where you can't bookmark anything and always have to start at the main page.  Can you give examples of the kinds of sites that can use this technique?

  • How about your on-line banking site?  Any web application that requires authentication (and is not anonymously accessible) would benefit from this type of mechanism.  

  • Hello,

    I don't understand how the canary token solved the fixation problem, as the hacker who created the legitimate session with the server shall also received the 'canary token' from the returned URL, then that hacker shall able to trick the target victim by using the hacker cookie and the token, right? I assume the hacker cookie can be transferred to the victim, else it's not required to have such canary token, as the non-existence of the cookie already prevent such fixation problem..

    Appreciate for any advice.

    Freddie

  • @Holyfield:  great example - thanks.

    @freddiechin:  cookies are not included in hyperlinks and can't be transferred via email (unless the attacker emails the cookie file and instructs the victim to install the cookie file into the cookie folder... and assuming the cookie hasn't expired -- IOW, not likely to happen).

  • Hello Aaron,

    Um.. I'm not sure if I catch your point, but if a hacker identified a XSS vulnerability in a webapp, may he/she can inject a cookie object into the victim machine via an email eg.. she/he can send email embeded with " http://onlinebanking.abc.com/<script>document.cookie="sessionid=1234”;</script>". Anyway, such scenario shall only exist/possible if the target webapp comes with XSS vulnerability.. But in this case, may the canary not able to fix the session fixation..

    Thanks

    Freddie

  • @freddiechin: I think the only way that could happen is if there was an XSS on a "landing page" (ie a page that doesn't require canary tokens). In this case, you're correct; the attacker could set cookies or simply use XmlHttpRequest to establish valid canaries and redirect. Otherwise though, I think the server canary validation logic would prevent the request from being processed.

    -Bryan

  • Hi,

    Admiring the hard work you put into your website and detailed information you present....good one...

Page 1 of 1 (10 items)
Leave a Comment
  • Please add 7 and 1 and type the answer here:
  • Post