309133 - Even more IDN URL-appearance-spoofing threat candidates

Status: RESOLVED DUPLICATE of bug 309311

(Core :: Networking, defect)

Description

[Neil Harris]

Many of the Unicode characters given in the HTML example below result in
potentially spoof-friendly display behavior in the location bar (spacing
characters) or non-display of these characters, or complete breakage of the
location bar display. Most do not generate DNS lookups, but some do, and in a
few cases, with DNS names that do not match the apparent URL displayed in the
location bar.

Note: The Unicode characters are all of those containing "SPACE" or "FILLER" in
their canonical names. 

1 Load the attached HTML page in Firefox
2 Click on the links
3 Look at the anomalous behavior in the location bar for many of these: 
* some are displayed as spaces: if there were enough of these space-like
characters, they would push the rest of the URL out of the right side of the
location bar
* others are not displayed at all, but still appear in the DNS lookup; 
* yet others appear to completely break the location bar display, making it just
say "ht" and nothing else 
4 Note that some of these generate DNS lookups as well as displaying misleading
content

Comment 1

[Neil Harris]

Attachment: HTML page containing test case links

This is the HTML page referred in the bug report.

Comment 2

[Gervase Markham [:gerv]]

I don't see complete breakage of the location bar, but this lot should
definitely be added to the blacklist. Patch, please :-)

Gerv

Comment 3

[Neil Harris]

Location bar breakage observed with Firefox 1.5b1 running on SuSE 9.1 upgraded
to KDE 3.4.2 and X.org X server.

Comment 4

[Neil Harris]

Other spacing characters that should be added to any blacklist are 
U+2000 EN QUAD
U+2001 EM QUAD 

Comment 5

[Neil Harris]

Another data point:

According to page 3 of "Ordering Rules for Hagul",
http://www.open-std.org/jtc1/sc22/wg20/docs/n891r-hangulsort10a.pdf, 
dated 2001, by Kent Karlsson:

"The two Hangul filler characters should normally not be explicitly used."

apparently referring to 

U+115F HANGUL CHOSEONG FILLER
U+1160 HANGUL JUNGSEOUNG FILLER 

which, incidentally, both completely break the rendering of nearby text in my
copy of Firefox 1.5b1 running on Linux. Apparently, these characters are to be
used as "virtual" characters in the internal mechanics of the renderer, rather
than encoded in exchangeable text streams.

Perhaps not coincidentally, the two other characters that screw up rendering in
my test are...

U+3164 HANGUL FILLER 
U+FFA0 HALFWIDTH HANGUL FILLER 

We need some input from Korean-language Unicode specialists about whether we any
of these characters are ever valid in properly-encoded Hangul Unicode text.

Comment 6

[Gervase Markham [:gerv]]

Bug 309311 has the canonical list of chars we are going to ban, including all of
those from this bug. We are going to use that set of chars as soon as bug
307438, which allows us to insert them into prefs.js in a sensible way, is fixed.

Gerv

*** This bug has been marked as a duplicate of 309311 ***