Issue metadata
Sign in to add a comment
|
Security: Chrome silently converts high-order-ASCII chars in domain names, which makes phishing easier
Reported by
bennetth...@gmail.com,
Sep 29
|
||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS This is being used "in the wild" (i.e. I am seeing this in real spam messages): A spammer sends me a link like https://pòf.com/verified/ashley901115/ Note that is the character "ò" in the domain name, ASCII 149 or 0x95. The domain name is clearly meant to phish users and confuse them into thinking it points to pof.com, the real "PlentyOfFish" website. Currently, if you access this domain name in the Chrome address bar, Chrome silently converts it to: https://xn--pf-2ja.com/verified/ashley901115/ and "xn--pf-2ja.com" is the real domain name that the spammer has actually registered. There is a strong argument that this silent behavior should be changed because: 1) High-order-ASCII is not allowed in a top-level domain name on the public Internet, so there is no legitimate reason for Chrome to even attempt to resolve these domain names, with or without converting them. (If you want to have high-order ASCII in a subdomain, like "josésmachine.mydomain.com", fine, but it should not be in a top-level domain name.) 2) On the other hand, it is very easy for spammers and phishers to abuse this feature. Possible fixes would be: a) Chrome silently refuses to resolve the domain name "pòf.com" b) Chrome refuses to resolve the domain name and displays an error dialog to the user, saying "You have attempted to access the domain name pòf.com. Special characters are not allowed in top-level domain names. This website may be trying to trick you." or something similar c) Chrome does convert the domain name "pòf.com" to "xn--pf-2ja.com", but first displays a warning page saying "You attempted to access pòf.com. You are being redirected to xn--pf-2ja.com which may not be the page you intended to access." This retains backward-compatibility in the extremely unlikely case someone needs to continue accessing a top-level domain with high-order-ASCII in it. d) Same as rule (c), but apply it to the entire hostname. Since Chrome already converts "josésmachine.blogspot.com" to "xn--jossmachine-dbb.blogspot.com", it can display a warning saying "You attempted to access josésmachine.blogspot.com; you are being redirected to xn--jossmachine-dbb.blogspot.com which may not be the page you intended to access." etc. I think any of these would be better than the current behavior, which is to silently convert the phishing domain name to another domain name which *has* been registered by the spammer. VERSION 68.0.3440.106 (Official Build) (64-bit) (cohort: Stable) Windows 10 Home v 1803 REPRODUCTION CASE Go to this url: https://pòf.com/verified/ashley901115/ Chrome silently converts it to: https://xn--pf-2ja.com/verified/ashley901115/ and then "xn--pf-2ja.com" is the real domain that the spammer has registered.
,
Oct 6
Oh. Thanks, my mistake, I didn't know those were considered valid. Still, couldn't Chrome display a message something like: "You have attempted to access the website pòf.com. You are being redirected to xn--pf-2ja.com. If you did not expect this redirect, the website may be trying to trick you." And then two buttons you can click before proceeding, which say: - Do not display this warning in the future for pòf.com. - Do not display this warning in the future for any website. Apart from considerations of the work involved in implementing it, if you had to choose between this behavior and the current behavior, wouldn't this behavior be better? (If you had to bet $100 one way or another, do you think that as phishers become more prolific, major browsers will allow the current behavior 5 years from now, with no warning at all?)
,
Oct 21
Is this still monitored, or do people stop posting responses after the bug is resolved "WontFix"? (In particular, I still think my question in the last post was valid: "Apart from considerations of the work involved in implementing it, if you had to choose between [the proposed] behavior and the current behavior, wouldn't [the proposed] behavior be better?")
,
Nov 8
bennetthaselton: Due to the large amount of bugs, it's not always possible for us to respond to all bugs, especially those that are closed, sorry about that. That said, I wanted to point out that we are working on an experimental mechanism (bug 843361) to help solve some of the challenges with internationalized domain names. The UX is still to be determined based on the metrics we see.
,
Jan 7
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 |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dominickn@chromium.org
, Sep 30Status: WontFix (was: Unconfirmed)