Share via

System.URI.AbsolutePath Vs Phishing Attack

  • Article

From Eugene Siu's blog: https://blogs.msdn.com/esiu/archive/2007/10/10/system-uri-absolutepath-vs-phishing-attack.aspx

Phishing attack can be caused by users inadvertently clicking on malicious links in emails or web pages, which then forward requests to malicious websites.  A common phishing technique is to fake emails sent by well-known banks or merchants,, which contain malicious hyperlinks.  Successful phishing attacks allow attackers to steal online user identities, install malwares on the users' computers, etc.

A careful user named Clever John checks each link before clicking it.  Some common phishing emails contain links with IP addresses, for example, https://123.123.123.123/notice .aspx.  Obviously, famous banks or merchants are not likely to use IP addresses on their public announcement emails.  Clever John decides not to click on emails that contain those suspicious links. 

What happen if the link is https://www.famousbank.com/notice.aspx?redirect=http%3a%2f%2f123.123.123.123%2fnotice.aspx ?   This time Clever John checks the link as usual, and sees that it is originated from https://www.famousbank.com.  In addition, the email graphically looks very convincing.  Little does Clever John know that he just gets attacked by a phisher who exploits a phishing security bug on https://www.famousbank.com, and malwares are installed on his machine quietly, as a result.

Let's analyze the code behind the phising security hole.  Here is sample code that is susceptible to phishing attack:

String redirectsite = request["redirect"];
response.Redirect(redirectsite);

Basically, the code redirects the server response to a location specified by redirect parameter in the request.  This is a common scenario, for example, redirecting to home pages upon logoff in the form of **https://www.famousbank.com/logoff.aspx?redirect=home.htm**.  Unfortunately, since redirect parameter is not verified, attackers exploit the hole to redirect requests to any sites of their choice.

In order to fix this bug, the redirect parameter MUST be validated.
* If the response should only be redirected to links of the same site, please check for " //" .  If "//" is present, it should be deemed as an invalid request.
* If the response can be redirected to external sites, more intelligent filtering must be in place.  Define all the valid sites that can be redirected, and allow to be redirected to only those valid sites. 

Someone asked if System.URI.AbsolutePath can be used to strip hostname and port number as a mitigation.  Then, redirect to the location returned by System.URI.AbsolutePath. 

Let's analyze what System.URI.AbsolutePath does. 

// link0.AbsolutePath returns " /default.aspx"
*Uri link0 = new Uri("*https://www.evil.com/default.aspx**");  

// link1.AbsolutePath returns " //www.evil.com/default.aspx"
Uri link1 = new Uri("https://www.evil.com//www.evil.com/default.aspx" );  

You may think " //www.evil.com/default.aspx" is not a valid address because it does not start with "http: ".  However, web browsers, such as IE and Fire, would gladly prepend "http: " in front of " //www.evil.com/default.aspx", and redirect to **https://www.evil.com/default.aspx**.  In other words, AbsolutePath alone is not effective against phishing security hole.

Phishing Attack wins in this heads-on "System.URI.AbsolutePath Vs Phishing Attack" battle .

Comments