Re: Attack vectors through Unassigned Code Points in IDN

From: Simon Montagu (smontagu@smontagu.org)
Date: Wed Mar 18 2009 - 13:57:02 CST

  • Next message: Simon Montagu: "Re: Attack vectors through Unassigned Code Points in IDN"

    This is indeed a Firefox bug, and will be fixed. The plan is to display
    IRIs containing unassigned code points in punycode, as Firefox does for
    other cases prohibited by IDNA.

    On 03/18/2009 07:00 PM, Shawn Steele (???) wrote:
    > (speaking as myself)
    >
    > Sounds like a Firefox bug. Unassigned code points should cause an error
    > since they aren’t assigned. If they were dropped, then at the least,
    > the shortened name should show up in the address bar.
    >
    > For most users this probably doesn’t matter much since you can easily
    > contrive URLs that look real at a quick glance or to someone not
    > familiar with URLs, eg: https://www.google.com.secure.net would fool
    > many users.
    >
    > -Shawn
    >
    > *From:* unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
    > *On Behalf Of *Chris Weber
    > *Sent:* Pōʻ, Malaki 17, 2009 10:06 PM
    > *To:* unicode@unicode.org
    > *Subject:* Attack vectors through Unassigned Code Points in IDN
    >
    > In I’m reading RFC 3491 correctly, then IDNA allows for unassigned code
    > points to exist in strings and domain names. This makes spoofing attacks
    > possible when one these code points don’t have associated glyphs and
    > basically show up as white space. This seems to be the case with some
    > ranges like U+115A..U+115E under. In this case the following URL
    > provides an attack vector in Firefox, because the domain nottrusted.org
    > gets pushed way out of view in the Address Bar.
    >
    > https://www.google.comᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚ.phreedom.org/ <https://www.google.comᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚᅚ.phreedom.org
    > />
    >
    > My question is – was this the intended behavior of IDNA to allow
    > unassigned code points in IDN? Or is this more related to a font
    > rendering issue?
    >
    > 7. Unassigned Code Points in Internationalized Domain Names
    >
    > If the processing in [IDNA] specifies that a list of unassigned code
    >
    > points be used, the system uses table A.1 from [STRINGPREP] as its
    >
    > list of unassigned code points.
    >
    > Thanks,
    >
    > -Chris
    >



    This archive was generated by hypermail 2.1.5 : Wed Mar 18 2009 - 13:59:24 CST