New issue
Advanced search Search tips

Issue 890589 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 30
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



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 description

VULNERABILITY 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.
 
Components: UI>Browser>Omnibox
Status: WontFix (was: Unconfirmed)
Thanks for the report. This is actually a fully specified and supported feature of the DNS system, called Internationalized Domain Names (IDN). See http://unicode.org/faq/idn.html. There is a 1-1 mapping between the punycoded ASCII domain and the domain with non-ASCII characters to allow DNS to continue to just be ASCII under the hood.

We cannot "refuse to resolve" such domains because they are entirely valid on the public internet. While IDN can be used to for phishing, we do a lot of work to try and combat that. For instance - displaying the full punycoded URL like you saw for easily-confused URLs. If you try entirely URLs that consist of less confusable characters (like Arabic script for instance), we often do not converted to ASCII because there is no phishing risk.

Additionally, the most effective form of phishing often involves no confusable characters at all - just something like secure-facebook.com.login is usually all you need. URLs are hard and we're investigating separate efforts to help humans understand them better.

It is a reality that the world has many more scripts than ASCII, and IDN allows users to register and use domain names in their native language - i.e. ensures that the web is not just US ASCII English only.
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?)
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?")
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.


Project Member

Comment 5 by sheriffbot@chromium.org, Jan 7

Labels: -Restrict-View-SecurityTeam allpublic
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