MSDN Magazine - March 2009 - (Page 105) BRYAN SULLIVAN SECURITY BRIEFS Protect Your Site With URL Rewriting 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 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), crosssite 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 site at owasp.org.) We could mitigate much of the risk of these vulnerabilities by frequently changing our URLs—not once every years but once every 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. We could mitigate much of the risk of these vulnerabilities by frequently changing our URLs. Now the attacker just needs to convince a victim to click on the link. Mass e-mails are an effective way to accomplish this, especially when a little social engineering is applied (for example, “Click here to receive your free Xbox !”). Similar malicious URLs can be constructed and e-mailed to exploit XSRF vulnerabilities: checking.aspx?action=withdraw&amount=1000&destination =badguy and open-redirect vulnerabilities: page.aspx?redirect=http://evil.contoso.com Open-redirect vulnerabilities are less well known than XSS and XSRF. They occur when an application allows a user to specify an arbitrary redirect URL in the request. This can lead to a phishing attack in which the user believes she is clicking a link that will take her to good.adatum.com, but in reality she will be redirected to evil.contoso.com. A Possible Solution: Personalized Resource Locators One possible solution to this problem is for an application to rewrite its URLs so that they are personalized for each user (or better yet, each user session). For example, an application could rewrite the URL contoso.com/page.aspx as contoso.com/{GUID}/page.aspx, where {GUID} is random and unique for each user session. Given that there are possible GUID values, it is fantastically unlikely that an attacker would be able to guess a valid one, so presumably he would not be able to craft and e-mail a valid (and poisoned) URL. ASP.NET already has similar functionality built in as part of its cookieless session-handling capability. Because some users can’t or won’t accept HTTP cookies, ASP.NET can be configured to store the user’s session ID in the URL instead. You can enable this with a simple change to your web.config file: Reviewing the Problem Before we get into the details of a solution, let’s take a closer look at the problem. Here’s a very simple example of some ASP.NET code vulnerable to an XSS attack: protected void Page_Load(object sender, EventArgs e) { // DO NOT USE - this is vulnerable code Response.Write(“Welcome back, “ + Request[“username”]); } The code is vulnerable because the page is writing the username parameter from the request back into the response without any validation or encoding. An attacker could easily exploit this vulnerability by crafting a URL with script injected into the username parameter, such as: page.aspx?username= On further inspection, however, we see that this approach does not really mitigate any of the security vulnerabilities that we’re concerned about, like XSS. The attacker may not be able to guess a valid session GUID, but he doesn’t actually have to. He can start Send your questions and comments to briefs@microsoft.com. March 2009 105 http://www.owasp.org http://contoso.com/page.aspx http://contoso.com/{GUID}/page/aspx
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.