Webmaster General Forum

Seriously tho', I can see this becoming a major issue once these lowlifes phishers get hold of it. Should be interesting to watch!

By the way, mac users are the most vulnerable (for a change) because of Safari's IDN support.

I find it suspicious that there's nothing more recent about them - strikes me the results weren't good enough for them to publish.

examples of IDN domain names [i-dns.net]

Added: According to Verisign, the IDN plugin for IE autochecks for updates every 24 hours. So if they fix this hole they should be able to fix all vul versions of IE pretty quickly.

<a href="http://www.microsoft.com/"><table><tr><td><a
href="http://www.google.com/">http://www.microsoft.com</td></tr></table></a>

Try it then run you mouse over the link using IE. When you mouseover the link, it should even show MS in the status bar. (NB: IE is is the only browser vulnerable to this form of link spoof. Outlook is the only email client vulnerable. This vulnerbaility was first noticed almost a year ago.)

Combine that with this, so the user is sent to the IDN which 301 redirects, and you have a heck of a whammy.

However, part of the problem with phishing isn't just browsers, it's often email clients. Eudora 6.2 comes with a built-in antiphishing tool called ScamWatch which compares the "displayed" URL with the "actual" URL and warns you if it's deceptive. It's a useful tool, and hardly rocket science. How it would cope with Unicode URLs I don't know though.

[support.microsoft.com...]

Here's a possible workaround to make it change the setting on startup everytime:
put this into user.js (using the chrome edit extension)

user_pref("network.enableIDN", false);

Really I think Firefox should change the address area's color when an IDN is present and I would bet an extension for that will be out within 48 hours.

An MSDN blog on the issue:
[blogs.msdn.com...]

ICANN's notes on the issue:
[icann.org...]

URL punycode explained at wikipedia:
[en.wikipedia.org...]

To me, that means the vuln is unpatched.

So how long before we see a patch for Firefox?

you need to edit to your compreg.dat For windows c:\Documents and Settings\$USER\Application Data\Mozilla\Firefox\Profiles\default.random\compreg.dat For UNIX ~/.mozilla/firefox/default.random/compreg.dat Open this file with a text editor which understands the line endings in it, such as Wordpad (or your favourite text editor on other platforms), and comment out all lines containing IDN by adding # at the start of the line. For example: # {4byteshex-2byteshex-2byteshex-2byteshex-6byteshex},@mozilla.org/network/idn-service;1,,nsIDNService,rel:libnecko.so Note that you will have to repeat this edit if you install any themes or extensions, as compreg.dat gets regenerated.

Looks like I'm going to start checking the 'view source' on a page before hitting a link to submit a payment.

ps. don't forget to visit windowsupdate today for your 13 patches to deal with issues months old

One surprising part of the story is the attitude of Opera Software, who consider that their implementation of IDNs is correct and so they have declined to make any changes. With such an inadequate response, perhaps Wells Fargo are right after all?

Well, their response may be tonedeaf, but it's not "inadequate". The problem isn't in Opera's implementation of IDN (or Mozilla's), but in the IDN spec itself.

just joking :)

So, in the mean time, the enableIDN preference will be set to "false" in Firefox 1.0.1 and Mozilla 1.8 beta, including all official localisations. An XPI will be made available to turn it on again; this XPI will make the risks of doing so clear. This means that by default, links to IDN domains which use the Unicode rather than the punycode form for the href will fail, and the browser will display any IDN domain visited in its raw form.

[weblogs.mozillazine.org...]

Firefox 1.0.1, released last week, shows Web addresses with foreign scripts in code, preceded by the letters "xn." So "paypal.com" with a Cyrillic "a" becomes "xn--pypal-4ve.com."