New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 774438 link

Starred by 3 users

Issue metadata

Status: Fixed
Closed: Nov 2017
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Security

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Security: Permission request UI spoof (improper URL truncation)

Reported by, Oct 13 2017

Issue description

Chrome Version: 61.0.3163.100/62.0.3202.52
Operating System: windows

spoof the origin to '*'
when the html page request camera or other permission

Online Demo

17.0 KB View Download
5.8 KB View Download
Components: UI>Security>UrlFormatting UI>Browser>Permissions>Prompts
Status: Untriaged (was: Unconfirmed)
Summary: Security: Permission request UI spoof (improper URL truncation) (was: Security: Permission request UI spoof)
We're showing the hostname of the URL from the left (truncating it before the end). If we must truncate, we need to elide from the left.

Comment 2 by, Oct 13 2017

Labels: Security_Severity-Low Security_Impact-Stable OS-Mac OS-Windows
Status: Assigned (was: Untriaged)
Over to raymes for permissions triage.

Marked as low severity because we think most users probably look at the omnibox rather than the origin in the permission prompt (which is also why we are getting rid of subframe permissions prompts that show the subframe origin).
Project Member

Comment 3 by, Oct 14 2017

Labels: Pri-2

Comment 4 by, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt
+mgiuca, lgarron, estark for thoughts on my fix.

I have a WIP CL for this that elides the entire title of the permission bubble from the head (i.e. left in LTR languages). This ensures that the most important part of the URL remains if the URL is too long to fit.

Anything more complex than operating on the entire title is somewhat complicated due to the way views/ works. My understanding is that bubbles don't actually know how wide they will be, but the width is a necessary piece of information to elide the URL.

There's also an issue if the translated title ends up being something like "wants to URL" or "wants URL to" - the "wants" will be elided if the URL is too long, so the title may be a bit weird. To me though, locking down the spoof and trying to address potential string strangeness is the right priority. Also, if really long URL cases are mostly malicious anyway, having the right part of the URL displayed and not the ancillary text also seems like the right priority

Attached are before and after representations of a too long URL.
Screenshot from 2017-11-14 14:22:10.png
90.0 KB View Download
Screenshot from 2017-11-14 15:52:29.png
72.3 KB View Download

Comment 7 by, Nov 14 2017

I discussed this with Dom and I'm OK with it from a security perspective. Doing anything better is hard. Clarifying a few things Dom said:

1. "if the translated title ends up being something like "wants to URL" or "wants URL to"" --- he means when translated into another UI language. For example, the Filipino (LANGUAGE=fil) string is "Gusto ng $ORIGIN na", which if the URL is very long will appear as "…$TRUNCATED_ORIGIN na". That's likely meaningless, but at least you'll still see the most significant part of the origin, and the list of permissions.

2. RTL origins are a consideration here, but fortunately should be correctly handled. Per Issue 650760, any RTL domain labels will be rendered as punycode for the time being (by FormatUrlForSecurityDisplay), which is actually kind of bad because the user has no idea what domain is asking for permission, but orthogonal to this issue. If we fixed Issue 650760, this would still render correctly by chopping off the START of the string (not the LEFT of the string), so we'll still see the most significant domain labels.

+cc mcgreevy who is thinking about a similar case for desktop PWA installation.
estark/lgarron: WIP CL is at It has approval to land; but I'd like one of you to confirm that what we've done here is okay as well. :)
Project Member

Comment 10 by, Nov 16 2017

The following revision refers to this bug:

commit 56762260ca8ef62578fa4718b7d47711f7e120dc
Author: Dominick Ng <>
Date: Thu Nov 16 00:44:57 2017

Elide the permission bubble title from the head of the string.

Long URLs can be used to spoof other origins in the permission bubble
title. This CL customises the title to be elided from the head, which
ensures that the maximal amount of the URL host is displayed in the case
where the URL is too long and causes the string to overflow.

Implementing the ellision means that the title cannot be multiline
(where elision is not well supported). Note that in English, the
window title is a string "$ORIGIN wants to", so the non-origin
component will not be elided. In other languages, the non-origin
component may appear fully or partly before the origin (e.g. in
Filipino, "Gusto ng $ORIGIN na"), so it may be elided there if the
URL is sufficiently long. This is not optimal, but the URLs that are
sufficiently long to trigger the elision are probably malicious, and
displaying the most relevant component of the URL is most important
for security purposes.

BUG= 774438 

Change-Id: I75c2364b10bf69bf337c7f4970481bf1809f6aae
Reviewed-by: Ben Wells <>
Reviewed-by: Lucas Garron <>
Reviewed-by: Matt Giuca <>
Commit-Queue: Dominick Ng <>
Cr-Commit-Position: refs/heads/master@{#516921}

Labels: M-64
Status: Fixed (was: Assigned)
c#10 landed in 64.0.3270.0 and should mitigate this spoofing vector. Closing as Fixed.
Project Member

Comment 12 by, Nov 17 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Nice one! The Chrome VRP panel decided to award $500 for this - thanks for the report!
Labels: -reward-unpaid reward-inprocess
Labels: Release-0-M64
Labels: CVE-2018-6049
 Issue 806708  has been merged into this issue.
Project Member

Comment 20 by, Feb 24 2018

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 21 by, Mar 27 2018

Labels: -M-64 M-65
Labels: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment