« CERT Advisory VU#435052: An Architectural Flaw Involving Transparent Proxies | Main | Apple goes public with security in Safari 4 »

Protect Your Site With URL Rewriting

Bryan Sullivan over at Microsoft has published a lengthy article on the advantages of URL writing to prevent certain types of attacks.

"Tim Berners-Lee once famously wrote that "cool URIs don't change." His opinion was that broken hyperlinks erode user confidence in an application and that URIs should be designed in such a way that they can remain unchanged for 200 years or more. While I understand his point, I'll venture to guess that when he made that statement he hadn't foreseen the ways in which hyperlinks would become a means for hackers to attack innocent users.

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. With all due respect to Sir Tim, while "cool" URIs may not change, secure ones certainly do."

Read more: http://msdn.microsoft.com/en-us/magazine/dd458793.aspx


Feed You can follow this conversation by subscribing to the comment feed for this post.

All Comments are Moderated and will be delayed!

You solve one problem with URL rewriting, but add another. URL-rewriting exposes session identification information in your browser history, in proxy servers, in webserver logs, etc. Even with a 10 minute window, the insider risk is so significant that OWASP recommends not using URL rewriting to prevent unnecessary session id exposure.

Thanks for the comment - I'm not proposing to write the session ID into the URL (ie standard URL rewriting) but instead to write a keyed hashed timestamp. This data does not identify a session in any way; you're meant to still keep the session ID in a cookie as usual.