General discussion


International Domain Names vulnerability

By apotheon ·
There are a fair number of reasons to value one browser over another. Two of the biggest, in the eyes of many, are web standards compliance and security. Once in a great while, those two concerns come into conflict. The matter of International Domain Name functionality is one of these instances.

Verisign, among others, has championed the IDN (International Domain Names) standard, allowing more than one linguistic script's characters to be used in domain names. A set of character entities called PUNYCODE has been implemented under that standard to allow browsers to navigate to domains using names rendered in other than the standard alphabet of the English language.

This is a noble endeavor, and something with which I agree in principle. Of course, non-PUNYCODE characters must also be accepted for backward-compatibility with pre-existing domain names. The problem arises in that, for instance, and http://www.pа don't lead to the same domain, even though they look the same when you link to them from a webpage in an IDN-compliant browser.

All gecko-based and khtml-based browsers are IDN compliant. This is, in and of itself, a good thing. It provides for added functionality and compatibility with what is beginning to look like the next step forward in domain name handling on the Internet. When the ability to spoof domain names for stealth-phishing through the browser comes into play, though, this raises the specter of a serious security vulnerability. A proof-of-concept page exists at where you can click on either of the "paypal" links to see how this "homograph attack" works. explains the history and security issue involved in some detail, including mentioning available workarounds to protect yourself. Unfortunately, the workaround description has a few problems.

1. There is no known workaround for Apple's Safari browser or the Opera browser. If you're using either one of these, you simply have to be very careful about what links you click. You can copy the URL into a text editor that lacks the ability to render Unicode and PUNYCODE, or otherwise tells you what character set is used to render the characters in the URL, but this is cumbersome and likely to be ignored by most users.

2. The explanation of how to implement the workaround for Gecko-based browsers is less than informative. I'll address this for users of Firefox (this should work for Mozilla and Netscape as well, though I won't swear to it at this time) below.

3. There's no mention of implementing a workaround for the Konqueror browser at all, despite the fact that it's the core KHTML-based browser available and the default browser tool of KDE in much the same way that IE is the default browser tool of the Windows GUI.

Interestingly enough, because Internet Explorer in many ways isn't even marginally standards-compliant, and hasn't adopted the IDN standard, it is (so far) free of this particular vulnerability. I'm of the strong opinion that the Mozilla method of handling it (including IDN functionality, but allowing it to be turned on or off at the user's discretion) is by far the superior approach, as it addresses both security and standards compliance rather than sacrificing one for the other as both IE and Opera do, but it is worth noting that this is the one and only innate security advantage of IE over other major browsers I've yet seen. I'd tend to choose IE over Opera or Safari, for instance, if this security issue were the only criterion.

NOTE: When I say "the Mozilla method" above, I refer to the manner in which all major Mozillalike Gecko-based browsers operate, which includes the Mozilla browser itself, the Netscape browser, and the Mozilla project's Firefox browser (my personal favorite).

Firefox work-around:
Your options, at this time, are either to allow IDN-compliant browsing and suffer the attendant vulnerability, or to disallow it entirely. For those of us who (pretty much) never browse outside the standard English language alphabet, IDN-noncompliance is the obvious better option, as security trumps functionality you don't use. For this purpose, I'll explain in very simple terms how to disable IDN URLs in the Firefox browser:

1. Open your Firefox browser.

2. Enter the following into the address bar.

3. Press the Enter key.

4. Scroll down to the following entry.

5. If that entry reads "true" under the Value column, double-click it. If it reads "false", leave it alone.

Voila! You're done. To double-check the new security protection you enjoy, navigate to and click on one of the paypal links there to see whether the homograph attack still works. Depending on which release of Firefox you're currently using, you may have to restart your browser after making configuration changes; I didn't have to with either of the two Firefox releases I have running here, on both Linux and Windows systems.

Safe browsing, everyone.

It has become clear that the above-listed fix fails to work in most cases, if not all. There has also been some talk of a fix that involves editing the compreg.dat file (setting any entries involving "idn-service" to 0 rather than 1), but that doesn't work at all in at least some cases, and also fails to be permanent after an extension is installed on Firefox (at which point those settings are reset).

Another fix has come to my attention which should ALWAYS work. Let me know if it doesn't work for you. Instructions follow.

1. Go to this page:

2. Download and install the Adblock extension for Firefox. You may have to turn on the ability to install software from a website in your preferences (under "Web Features"). I recommend disabling the software isntallation feature when you're not actively using it.

3. Open the Adblock preferences dialog (Adblock settings are under the Tools menu).

4. Open "Adblock Options", and check the "Site Blocking" option.

5. Place the following string of characters in the "New Filter" field: /[^\x20-\xFF]/

6. Click "Add", and confirm that you want to include this "regular expression" as a filter. Whether or not you select "I know what I'm doing" is up to you.

7. Click "Done".

When this is accomplished, IDN-based URL spoofing won't work. There will be no error messages: the link will simply not act like a link. Clicking on it will accomplish nothing.

I have confirmed that, with multiple Firefox releases, this survives browser restarts.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Netscape 7.1

by awfernald In reply to International Domain Name ...

Tried this with netscape 7.1, network.enableIDN defaulted to false, so I left it alone. However, both links took me to meeoow.

Collapse -


by apotheon In reply to Netscape 7.1

You probably have to switch it back to True, then to False again. Unfortunately, that seems to be the case every time some versions of Gecko-based browsers are restarted. I only discovered this after this discussion was first posted, I'm afraid. I'm looking into figuring out a fix, or finding out if one already exists, for affected browsers.

Collapse -

That fixed it

by awfernald In reply to reset

Thanks. I did that, but forgot to restart browser after.

Collapse -


by house In reply to International Domain Name ...

Thanks for that one. Where could I find more info on the gecko configurations? Let me guess, LUGs?!

Chris :)

Collapse -


by apotheon In reply to Unbelievable

Yeah, LUGs should be a good source of info.

Collapse -

Worked for me

by Tony Hopkinson In reply to Hey, apotheon

Still safe after restart of Firefox 1.0 under XP.
Will check it again after reboot, not to mention after adding an extension. Post_It note applied to moni tor.

Collapse -


by apotheon In reply to Hey, apotheon

Thanks for the link. I'm checking into it.

EDIT: Okay, I've checked. In the course of testing, it doesn't seem to work, actually. I'm not sure why.

Collapse -

new fix

by apotheon In reply to thanks

I've added more text to the original post, explaining how to use the Adblock extension to block all IDN-based URLs that spoof normal ASCII URLs. This one actually seems to work in all cases, and doesn't stop working when settings are changed or when the browser is restarted.

Collapse -

Something strange going on here

by Tony Hopkinson In reply to new fix

This first fix in about did work for me. But only survived one restart.
I did the second one, but that was wiped out by adding the adbock extension.
Unless I've been a stupid user and misunderstood the instructions adblock is not doing it's job and I'm still vulnerable

Related Discussions

Related Forums