Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: phranque
In theory this can be blocked at least in Firefox by turning off international domain support (IDN) as a temporary workaround:
type about:config in your address bar
search for network.enableIDN
click on it to set it to FALSE
IDN support should then be disabled
[edited by: trillianjedi at 6:00 pm (utc) on Feb. 7, 2005]
[edit reason] Fixing boldening [/edit]
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.
It's simply not popular in english speaking countries because you need a special keyboard to be able to enter the special characters (in a quick manner).
examples of IDN domain names [i-dns.net]
I see that up to 8% of all registered domains are IDN, which is we take 66.8M TLDs as being currently registered gives us aprox 5,344,000 IDN TLDs worldwide.
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.
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.
Who's laughing now? :)
Yeah, but the score is still:
Internet Explorer: 2
Mozilla-Firefox United: 876
or something ;)
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.
to false, IDNs are disabled - but once you restart the browser the value remains false but the IDNs work again. So, we have a bug compounded by another bug, and a false sense of security brought about by a broken workaround.
Here's a possible workaround to make it change the setting on startup everytime:
put this into user.js (using the chrome edit extension)
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:
ICANN's notes on the issue:
URL punycode explained at wikipedia:
you need to edit to your compreg.dat
c:\Documents and Settings\$USER\Application Data\Mozilla\Firefox\Profiles\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:
Note that you will have to repeat this edit if you install any themes or extensions, as compreg.dat gets regenerated.
For those that need to keep IDN support working, try using the the firefox spoofstick extension
which has now been updated to highlight domains with extended ascii (IDN) characters:
ps. don't forget to visit windowsupdate today for your 13 patches to deal with issues months old
Who's laughing now? :)
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?
It isn't that IE's implementation is not vulnerable, it's just that the vulnerability is in a feature that IE doesn't even support
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.