New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Closed: Sep 17
EstimatedDays: ----
NextAction: ----
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 852634: Security: Chrome for iOS URL spoofing using location.replace and history.back

Reported by, Jun 14 2018

Issue description

Attacker could spoof URL using location.replace() behavior.
Seems related to

1. Page from calls location.replace(
2. Page on calls history.back()
3. At this point, we've got page with content from, but URL in address bar is

Running PoC in debug build, leads to the page on spoofed url alerts "embedded page...". 
As far as I understood, location.replace(<nextPage>) creates a kind of "intermediate" window on the replaced page, which has <nextPage> as top frame. This "top frame" doesn't have any restriction on embedded resource, so X-FRAME-OPTIONS doesn't work. 

Additionally, no warnings about self-signed cert on shown in the spoofed page's address bar.

Chrome Version: 67.0.3396.69 stable + 69 dev debug
Operating System: iOS 11.4 (15f79), real device


1. Start 2 local servers (localhost:3000 for "3000" folder and localhost:5000 for "5000" folder)
2. Open localhost:3000
3. Navigation to localhost:5000 initiated
4. Page alerts 'I am going back ... 5000' and calls history.back()
5. location in address bar = localhost:3000, "real" location = localhost:5000 (localhost:5000)
        if (document.cookie.includes('here=1')) {
            document.cookie = "here=0";
            alert('This is not localhost:3000, real location:' + location);
        } else {
            document.cookie = 'here=1';
            alert('I am going .back(), real location' + location);
        document.write('<h1>' + location + '</h1>')
    <a href="" /> What's my referrer?</a>
``` (localhost:3000)
        window.onload = () => {
            if ( === '') {
                // looks like this block is required in most cases 
                // But it's also possible to spoof using location.replace only
                // actually, this snippet was "stolen" from Chrome iOS tests 
                history.replaceState({}, 'reload', '?reload');
            } else {
                const host = '' || 'localhost'

Screencast attached.
video (3).mp4
831 KB View Download
1.2 KB Download

Comment 2 by, Jun 14 2018

Components: UI>Browser>Navigation
Labels: Security_Severity-Low Security_Impact-Stable OS-iOS Pri-1
Status: Assigned (was: Unconfirmed)
eugene can you take a look at this please?

Comment 3 by, Jun 14 2018

Srikanth, could you please check if this bug is reproducible with slim-navigation-manager

Comment 4 by, Jun 14 2018

NOT able to reproduce this with #slim-naviagation-manager enabled.
Tested on 69 ToT, with the given html pages.
Since there is no live pages to test, I tested this on iOS11.4 Simulator.

Comment 5 by, Jun 14 2018

Labels: M-68
Will be fixed in M68 if we ship slim-naviagation-manager

Comment 6 by, Jun 15 2018

Project Member
Labels: -Pri-1 Pri-2

Comment 7 by, Jul 10 2018

Labels: -M-68 M-69
slim-naviagation-manager was postponed to M69.

Comment 8 by, Sep 17

Than you for reporting this bug. Is it possible to spoof URL scheme or hostname? Or this vulnerability only affects port?

Comment 9 by, Sep 17

It was possible to spoof both scheme and hostname.

I was able to spoof even SSL lock, however, don't have a meaningful PoC to show.

Comment 10 by, Sep 17

Labels: -M-69 M-70
Thanks! I tested attached PoC with top of the tree and M70 branch. When I load localhost:5000, there is no client redirect to localhost:3000 and the page stays on localhost:5000. So I think this should be fixed in Chrome version 70.

Comment 11 by, Sep 17

Confirm that it was fixed.

Comment 12 by, Sep 17

Status: Fixed (was: Assigned)
Thanks a lot for checking this!

Comment 13 by, Sep 18

Any CVE/bounty?

Comment 14 by, Sep 18

This bug will go through reward panel.

Comment 15 by, Sep 18

I often saw CVE is issued before the fix. 
So I've asked about that because maybe the bug isn't valid for VRP or there are some iOS-specific restrictions. Thanks again!

Comment 16 by, Sep 18

No worries, Vladimir. Thank you for the bug report.

Comment 17 by, Sep 18

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 18 by, Sep 24

Labels: reward-topanel

Comment 19 by, Sep 27

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.

Comment 20 by, Sep 28

Great, thanks!

Also, please, could someone check [1]?
That's an already resolved issue about AppleScript on macOS. 
However, nobody replied to my comment, but I think the provided info may be useful for Chrome, even if the impact of this issue is minor.

[1] -

Comment 21 by, Sep 28

Most welcome,  vladimirmetnew@! A member of our finance team will be in touch to arrange payment.  Also, how would you like to be credited in our release notes?

As to [1], would you mind filing that as a new bug? It'll then get picked up by our sheriffs and can be triaged and tracked separately.  Cheers!

Comment 22 by, Sep 28

Labels: -reward-unpaid reward-inprocess

Comment 23 by, Sep 28

I guess "Vladimir Metnew" sounds good for release notes)

Sure, I'll fill a new bug.

Comment 24 by, Oct 15

Labels: Release-0-M70

Comment 25 by, Oct 16

Labels: CVE-2018-17475 CVE_description-missing

Comment 26 by, Nov 12

Labels: -CVE_description-missing CVE_description-submitted

Comment 27 by, Dec 25

Project Member
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

Sign in to add a comment