URL rewriting can help thwart Web app attacks

According to Bryan Sullivan, security program manager for Redmond's Security Development Lifecycle team, Web developers should consider URL Rewriting as a technique to ward off hackers looking to exploit Web app vulnerabilities.

Here's the gist of Sullivan's recommendation:

• Attacks like cross-site scripting (XSS), cross-site request forgery (XSRF), and open-redirect phishing are routinely propagated through malicious hyperlinks sent in e-mail messages. (If you're unfamiliar with these attacks, I recommend reading about them at the Open Web Application Security Project (OWASP) Web.) We could mitigate much of the risk of these vulnerabilities by frequently changing our URLs -- not once every 200 years but once every 10 minutes. Attackers would no longer be able to exploit application vulnerabilities by mass e-mailing poisoned hyperlinks because the links would be broken and invalid by the time the messages reached their intended victims.

Of course, there are some caveats, especially in cases where bookmarking and e-mailing static links are necessary:

• URL rewriting may not be appropriate for all applications. One negative side effect of this approach is that although attackers are no longer able to e-mail malicious hyperlinks, legitimate users are similarly prevented from sending valid links or even from bookmarking pages in the application. Any page marked as a landing page could be bookmarked, but as I mentioned before, you need to be very cautious when using landing pages. Therefore, if you expect users of your application to bookmark pages other than the home page, URL rewriting is probably not a good solution for you.
• Additionally, while URL rewriting is a fast and easy defense-in-depth mechanism, it is just that: defense-in-depth. It is by no means a silver bullet against XSS or any other attacks. An automatically expiring URL can still be exploited by an attacker with access to a Web server of his own. Instead of sending out malicious hyperlinks that point directly to the vulnerable page, he can send out hyperlinks that point to his own site. When his site gets a hit from one of the phished e-mails, it can contact a landing page on the vulnerable site to obtain a valid time stamp and then redirect the user accordingly.

Sullivan argues that URL rewriting does make the attacker's work more difficult: he now has to convince a user to follow a hyperlink to his Web site (evil.contoso.com) rather than a trusted one (www.msn.com), and he is also leaving a very clear trail back to himself for law enforcement agencies to follow. However, this will probably be of little comfort to any victims who fall for the phished e-mail and have their identities stolen as a result.

• Do use URL rewriting as an extra defensive measure, but always be sure to address vulnerabilities at the root of the problem.

Read the entire article here.