New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
Pri: 2
Type: Bug-Security

Sign in to add a comment

Security: URL spoofing via forward and backward navigation on iOS

Reported by, Jan 25 2018

Issue description

Chrome Version: 64.0.3282.97
Operating System: iOS

Steps to reproduce:
1.) Load
2.) Load
3.) Go Back
4.) Long press forward to invoke navigation history popup
5.) Quickly tap on gmail entry in history and back

Actual result:
Displayed URL is

Expected result
Displayed URL is
WhatsApp Image 2018-01-25 at 15.19.13.jpeg
50.2 KB View Download
Please watch the video.

Also, in another example, in Screenshot_2 you can see the content of is seen with URL in the omnibox with green lock, and it's definitely bad behavior.

64.3 KB View Download

Comment 2 by, Jan 29 2018

Components: UI>Browser>Navigation
Thanks for the report. Unfortunately I don't have an iOS device to test this right now, so preemptively adding navigation label.

chromium.khalil: Is the data URL required for this bug? Note that a webpage cannot navigate the top level frame to data URLs.
No, There is no need to thet data URL.

Comment 4 by, Jan 29 2018

Do you mean it could instead be served over http?
I meant we can use a http URL instead of that URL data.

Comment 7 by, Jan 30 2018


Comment 8 by, Jan 30 2018

iOS uses a different navigation stack.  Eugene, could you help triage this?

Comment 9 by, Jan 30 2018

Labels: OS-iOS
Labels: ReleaseBlock-Stable M-65 Pri-1
Status: Assigned (was: Unconfirmed)
I could not reproduce this bug with 64.0.3282.112 from AppStore. 64.0.3282.97 is not the latest version and I remember we recently fixed one URL spoofing bug for M64.  chromium.khalil, is this bug reproducible with 64.0.3282.112? Thanks.
Yes, I am able to repro this bug on Beta and stable (64.0.3282.112). It sometimes takes several tries to repro. 
Labels: Needs-Feedback
Srikanth, can you try reproducing this bug?
I can't repro it so far on M64.0.3282.112 stable app.
Tested on iPhoneX, iPhone8 plus.
Note: When I repro this bug, I can see there is something weird (inside the red square), it seems like the navigation (via backward or forward button) is incomplete or failed which resulted the spoofing URL
179 KB View Download
I found a more reduced test case:

1. Go to any website e.g
2. Then go (must be logged in)
3. Back to 
4. Hold forward button and click on "" and click quickly on forward button

Also, I was able to repro this with different URLs instead of, but it does take several attempts to repro.
I tried with a fresh installation of M64 stable version Chrome app but still no luck.
What version iOS are you using. Can you also copy/paste the contents of about://version page. I will try to repro on few other devices tomorrow.
Google Chrome	64.0.3282.112 (Official Build) stable (64-bit)
Revision	7ceafc6ca46e...
User Agent	Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_2 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15C202 Safari/604.1
Command Line	--flag-switches-begin --flag-switches-end
Variations	3095aa95-3f4a17df
iOS 11.2.2 and I have also tried on 10.3.3.
Weird, I repro-ed this very easily, did you try with logged-in as I mentioned in C#16?

RE #21: I wasn't able to reproduce this using a 2017 iPad. 

Reproduction is probably a race condition of some sort, so it may be helpful to know what hardware you were able to reproduce this on?
I’m using iPhone 5 and 6. I’ll try to repro on iPad.
I tried on M64, iPhoneX iOS11.3, iPhone7 iOS11.1.2, iPhone7Plus 10.3.3
Not able to repro. Noticed in some cases tapping on back arrow redirecting to NTP instead of but that seems tobe a different navigation bug.
As far as this bug, still trying to repro.
I am signed into in content area and in Settings.
crbug url not updating repro
4.7 MB View Download
You don't have to wait until you accessing the page content of, you should click quickly on back arrow after holding (forward arrow) and clicking on "".
2.1 MB View Download
Got it. Thanks for the tip.
Bisecting now.
Labels: -Needs-Feedback
Eugene: I went back upto M61 stable and its reproduced on all of the builds.
Also on M65 and 66 canary.
Let me know if you need any other information from me.
I followed repro steps from comment#26 video.
Labels: Security_Impact-Stable Security_Severity-Low
Project Member

Comment 30 by, Feb 1 2018

Labels: -Pri-1 Pri-2
Description: Show this description
Root cause:
When the user taps on "gmail entry in history" Chrome loads gmail
When the user taps on Back button Chrome starts loading outlook

After that gmail page creates renderer-initiated navigation. That renderer initiated navigation calls navigationManagerImpl->UpdatePendingItemUrl which overrides to
Project Member

Comment 35 by, Feb 6 2018

The following revision refers to this bug:

commit fcdd81192c7bc9785b62a8f796ea953d681d1d1d
Author: Eugene But <>
Date: Tue Feb 06 02:28:04 2018

Do not create a pending entry for windows opened by DOM.

Creating a pending entry is cruft code from UIWebView world. This
pending invalid new entry is later updated by
NavigationManager::UpdatePendingItemUrl, which is also cruft code from
UIWebView world.

The problem is that NavigationManager::UpdatePendingItemUrl does not
always work correctly and causes ( ). It is necessary to
stop creating an invalid pending entry before removing

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: If478c574f11e5e586fac7407085f57ec05079814
Reviewed-by: Sylvain Defresne <>
Commit-Queue: Eugene But <>
Cr-Commit-Position: refs/heads/master@{#534594}

Thanks for the fix!
This is not the fix yet. But this landed CL should unblock the fix.
Project Member

Comment 38 by, Feb 9 2018

The following revision refers to this bug:

commit 91fe94ba1ada82a4673f8329dbe243e44f3287f4
Author: Eugene But <>
Date: Fri Feb 09 15:04:53 2018

Cleaned up didReceiveServerRedirectForProvisionalNavigation:

Do not call registerLoadRequestForURL: just to update pending item URL.
Use NavigationContext as a source of truth for URL update instead.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: Idb26cf953088a0dafcdb8c80396f2bca93d30c16
Reviewed-by: Danyao Wang <>
Commit-Queue: Eugene But <>
Cr-Commit-Position: refs/heads/master@{#535711}

Comment 39 by, Feb 12 2018

What's the update on this blocker. M65 release is nearing
Labels: -M-65 M-66
Punting to M66. We need to land a few more CLs to fix the bug and CLs which were landed already are not very safe.
Project Member

Comment 41 by, Feb 14 2018

The following revision refers to this bug:

commit 03a75113ce67157d31d9743ab7440939271d30cc
Author: Eugene But <>
Date: Wed Feb 14 23:13:57 2018

Change post request to get in didReceiveServerRedirectForProvisionalNavigation.

This was copied from UpdatePendingItemUrl method which will be removed
in a separate CL.

Also reset _lastTransferTimeInSeconds for server redirects.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I79f846c9d4777fc45abff220632a7afc80819d0a
Commit-Queue: Eugene But <>
Reviewed-by: Danyao Wang <>
Cr-Commit-Position: refs/heads/master@{#536869}

Status: Started (was: Assigned)
Project Member

Comment 43 by, Feb 21 2018

The following revision refers to this bug:

commit 74c0d72561c3bea1cb87ba9bfe9f7e7201a1e650
Author: Eugene But <>
Date: Wed Feb 21 22:53:08 2018

Do not update Pending Item URL with URL that have a different origin.

NavigationManagerImpl::UpdatePendingItemUrl exists to update the URL
for redirects. UpdatePendingItemUrl is no longer used for server side
redirects, so this change makes sure that pending item origin is never
changed to prevent URL spoofing bugs.

Conceptually this is not the right fix, because NavigationManager
assumes that there can be only one pending navigation (which is not
true with WKWebView). The right fix would be to switch to WK-based
navigation manager, so this CL is just a workaround.

Bug:  805900 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I20eed4a661244c0fec52a87b088c0620c5f57036
Reviewed-by: Danyao Wang <>
Commit-Queue: Eugene But <>
Cr-Commit-Position: refs/heads/master@{#538237}

Status: Fixed (was: Started)
Project Member

Comment 45 by, Feb 22 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Any bounty for this report? Thanks!
Labels: reward-topanel
Let's see what the panel says :-)
Labels: -reward-topanel reward-0
I'm afraid the VRP panel declined to reward for this bug, citing how much user interaction was required and how it's mitigated. If you have a PoC that requires less user interaction, we could reconsider it.
Labels: -ReleaseBlock-Stable
Labels: Release-0-M66
Labels: CVE-2018-6113
Labels: CVE_description-missing
Project Member

Comment 53 by, May 31

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