Issue metadata
Sign in to add a comment
|
Security: Possibility for emoji in IDNs to allow spoofing a web addresses
Reported by
jpjeffer...@gmail.com,
Jul 6 2016
|
||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS I noticed this morning that I was able to register www.xn--google-i148c.tk which when parsed in certain applications result in the address appearing as www.google.tk as xn--i148c is not a valid emoji character. Same can be replicated on the .ws nic where I first noticed that registering www.xn--i148c.ws resulted in the web address www..ws (This is no longer working but is still available for manipulation on my iwantmyname account. As chrome currently doesn't support emojis this doesn't affect it yet. Using Safari however did lead me to a mixed up website where it was trying to display what is actually at website.ws and the holder screen that www.xn--i148c.ws was assigned upon registering. VERSION Chrome Version: N/A warning for future adaption Operating System: Mac OSX 10.11.5 REPRODUCTION CASE http://www.xn-i148c.ws (no longer shows what happened above and is asking for someone to register it) http://www.xn--google-i148c.tk was set up to forward to google.com and is attempting to currently at 14:22 6/July Replicated registration proof: http://my.dot.tk/registration/register?domainname=xn--google-i148d Shows the user as capable of registering google.tk - with the right capabilities it seems entirely feasible that this will be fully able to cause the user to believe they are on an official google domain (albeit a .tk/.ws domain) allowing for other forms of web attack. (Please do not register xn--google-i148d as it is for the example!)
,
Jul 6 2016
Should Chrome always show domain names that have invalid Unicode code points (of any kind) as Punycode? Is this bug more about invalid code points in IDNs than about emoji per se?
,
Jul 6 2016
I should have term it as punycode not emoji (but as I was looking into how emojis could/can work within domains got me to that point I was at this morning hence the chosen wording) I have been looking it up a lot more after submitting this and realised its a topic that has already been explored (in some depth by others https://www.chromium.org/developers/design-documents/idn-in-google-chrome) With that in mind it seems unnecessary to delve deeper into :) Sorry for taking your time up!
,
Jul 6 2016
I don't know the IDN rules, but Jungshik does.
,
Jul 6 2016
Also see the Enamel thread titled "IDNA domains in non-native locales?"[1]. [1] https://groups.google.com/a/google.com/forum/#!topic/chrome-security-enamel/QBaSQy4CmkU
,
Jul 7 2016
> As chrome currently doesn't support emojis this doesn't affect it yet. Just to clarify, this is *not* an active issue in any version or platform of Chrome, correct? (Just a theoretical future issue if we support emoji in domains?) I think this is a non-issue (the reason we don't support emoji in domains is probably for security, not because we haven't gotten around to it yet). jshin@ can confirm.
,
Jul 7 2016
Marking as Medium (because if this were an issue it would be medium) but Impact-None as I don't believe it currently impacts any Chrome version. jshin: If you determine that this is not an issue, please close the bug (and make whatever precautions are necessary to make sure this doesn't come up in the future).
,
Jul 7 2016
,
Jul 15 2016
Sorry for being late here. bug 508378 is about Emoji in IDN. As for unassigned code points, Chrome certainly uses punycode because we block unassigned code points. In addition to unassigned code points, a whole lot of characters are blocked. Allowed characters are the union of Characters allowed in identifiers per Unicode Technical Standard 39 (UTS 39) Characters suitable for identifiers in 5 Aspirational scripts per Unicode Standard Annex 31 (UAX 31) On top of this character-level restriction, other checks (script mixing, bidi, etc) are done.
,
Oct 22 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 9 2016
Security>UX component is deprecated in favor of the Team-Security-UX label |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jpjeffer...@gmail.com
, Jul 6 2016