Update: Well, things are a bit more complex. Looks like RFC3986 actually endorses the use of URL encoded host names. Earlier RFCs (see references in RFC3986) did not.

One of our handlers (Bojan) found a hostname like this in his DNS cache:

www.paypal.com%20cgi-bin%20...(more )...example.com

This method appears to be used for a while, but I guess we missed it among all the phishing going on these days. Upon further investigation, we found that some browsers allow URL encoded host names. The impact is similar to the old (no longer working) method of using the "username:password@url" notation. So the impact is not "huge", but its yet another trick in the phishing arsenal.

Theoretically, a host name should only contain letters A-Z, numbers 0-9 and dashes (-). In order to support foreign character sets, "IDN" is used with uses that same set of characters to encode. For domain names, this is enforced by the registrars, but host names for existing domains are up to the user, and DNS servers typically allow "anything" (after all, DNS can be used for other things then host names).

We found that Internet Explorer, Safari and to some extend Opera will accept URL encoded host names and redirect to the "decoded" version. Further, they will allow spaces as part of host names. This is used by phishers to obfuscate URLs.

Explorer and Opera will accept the URL encoded host name, and redirect to it. But once you arrive at the page, the URL bar will show the URL in clear text.

Safari does accept URL encoded host names as well, but will NOT decode it as you arrive at the destination page.

Firefox refuses to use URL encoded host names.

Simple sample to test (not clickable, copy&paste):

http://www.paypal.com%20cgi-bin%20webscr%64%73%68%69%65%6c%64.%63%6f%6d

or try a host name with space vs. without (less of an issue as you would have to control DNS for the domain to use it)

http://www .securewebbank.com   (vs. http://www.securewebbank.com )

URL encoding is only supposed to be used after the host name to encode the file name and the GET parameters.

Suggested defenses:

• Inform users about this problem.
• Audit DNS caches to see if users asked to resolve such a host name.
• Audit proxy logs for such domains, and filter if possible.