IDN homograph attack possible for letters similar to "i"
Categories
(Firefox :: Address Bar, task)
Tracking
()
People
(Reporter: arkadiusz.bany, Unassigned)
References
Details
(Keywords: csectype-spoof, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Attachments
(1 file)
1.72 KB,
text/html
|
Details |
User Agent:
- Firefox 78.0.2 (64-bit) on macOS 10.14.6
- Firefox for Android 68.10.1
Steps to reproduce:
- Open attached HTML file.
- Click example links containing non-ASCI characters similar to latin letter "i" (U+0131, U+00ED, U+00EC, U+1EC9, U+1ECB).
Actual results:
Address bar renders all characters as unicode characters.
Expected results:
Punycode should be used for all non-ASCI characters.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Dot below shows punycode for me.
All the other ones are latin characters or combining marks used together with other latin characters - in other words, they are single-script addresses. This can't be disallowed in general (or Vietnamese or Turkish or ... domain names would never render correctly). My understanding is some other browsers disallow these right now based on OS language settings (Edge) or whether they resemble one of the most popular ascii domain names (Chrome). We have not yet decided for or implemented either of those restrictions, given that both have drawbacks: the former means domain rendering differs between users and cannot be predicted, and effectively disadvantages IDN domains compared to their ascii counterparts as their rendering cannot be relied upon; the latter privileges a small set of popular websites against the rest of the internet (ie less popular sites are not protected).
Jonathan, can you sanity-check my comment? I'm guessing we should dupe to bug 1507582 or similar.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Right, we're not going to disallow accented or non-ASCII letters in general. That would be far too English-centric.
Something along the lines of bug 1507582 is probably the only reasonable way to provide more "protection" for inattentive users (though I think in practice things like registrar policies and SafeBrowsing checks are a more important part of the picture).
Comment 3•4 years ago
|
||
Should this stay private if we dupe to Bug 1507582? The other similar ones are not, afaict.
Comment 4•4 years ago
|
||
I don't think there's any reason for it to stay private.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•1 year ago
|
||
We did fix some spoofs of the letter 'i' in bug 1473911, but that was more opportunistically grabbing some low hanging fruit so it's still best to leave this duped to the more general fix
Description
•