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
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.
Posted by: Jim Manico | Feb 23, 2009 7:28:40 PM
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.
Posted by: Bryan | Feb 25, 2009 10:33:47 AM