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

Issue 841105 link

Starred by 8 users

Security: uXSS in Chrome on iOS

Reported by, May 9 2018

Issue description

Universal XSS by using "..;@" within the url :~D

Chrome Version: [66.0.3359.122] + [stable]
Operating System: [iOS]


Basically if we run this javascript code " history.replaceState('','','..;') " from any domain using "HTTPS:" our URL domain is being replaced to that one..

For example: if this code is run on my site the the url is being replaced to yet the contents remain under my control.. Therefore etc. we can run unrestricted XHR requests as long as the path is not absolute ('../myAccountInfo','../../SomeOtherSensitiveInformation')

Proof of Concept displaying Cookies in an iframe from

This should work fine on any iOS on Chrome

Hope you like it! :~D

Labels: OS-iOS
Summary: Security: uXSS in Chrome on iOS (was: Security: uXSS in Chrome on iOS :D)
Components: UI>Browser>Mobile Mobile>WebView>Glue
Labels: M-66 Security_Severity-High Security_Impact-Stable Pri-1
eugenebut: Could you take a look at this?

I don't have an iOS device to test with, so leaving Unconfirmed but applying the labels as if it were for tracking.
Labels: -M-66 ReleaseBlock-Stable M-67
thomi@, is this bug reproducible in Safari or Firefox?
This is a URL spoofing bug, where omnibox URL is incorrectly displayed. But I don't see XSS and "This are your cookies from '': don't print cookies.

Comment 5 by, May 9 2018

First.. Make sure you got some cookies already from in the first place in case you are using incognito ;)
Secondly make sure you are accessing my PoC over HTTPS! Otherwise it will not work as the Origin does not mach HTTP..

Thirdly it's kind of weird.. if you do alert(document.domain) it will come back as: says:
Yet we have access to cookies and we can do unrestricted XHR requests...

Do you want different types of examples of PoC?

Comment 6 by, May 9 2018

Also this PoC only works on Chrome on iOS...
There are different ways to achieve that on other browsers on iOS or Safari on Mac but I think is irrelevant as this subject only focuses on Chrome.. Right?
It would be helpful if you could include screenshots of your reproduction.

(We are interested in understanding whether this reproduces in Safari and Firefox on iOS to better understand whether the root cause of the bug is in WebKit, or in WKWebView, or in Chrome code, which will help speed up the triage process).
Status: Assigned (was: Unconfirmed)
Firefox crashes and I can reproduce this bug in stock WKWebView by executing very short JavaScript. rdar://40109702

Danyao, could you please take a look if this is something you or Ali can fix in WebKit? All the information is available with rdar://40109702.

Pink, could you please escalate this bug with Apple.

I will think if we can workaround the issue.

Comment 9 by, May 10 2018

Here is a new Proof of Concept:
Works on Chrome on iOS only...

Also I have attached screenshots what comes up on my screen.

Do you still want to me to create another PoC for Safari? Or you don't need it anymore?
Yes please create a PoC for Safari. It will help with our discussions with Apple. 
I escalated to our ADR team. 
Thank you Tomasz! It looks like some time is needed for XSS attack to steal cookie from iframe. As a workaround we could crash the browser once we detect the attack.

In your previous comment you mentioned that the vulnerability also allows to perform unrestricted XHR. Do you think it would be possible to execute XHR-based attack faster than iframe-based attack? Crashing the browser will limit the time available for the attack to succeed.
Developed a workaround to crash when URL change is detected. The crash will reduce the time available for this attack, which should either mitigate or make the attack impractical. The fix will be landed behind the finch flag:
We briefly discussed in OH if this ever could happen for legitimate sites. What's the risk or likelihood of that?
+mardini as FYI
I believe it's unlikely that legitimate web sites would execute "history.replaceState('','','..;@another_domain/')" script. The crash will be launched behind the flag, so I guess we'll see if legitimate web sites crash.

Comment 17 by, May 10 2018

So.. Here is PoC that should work on Safari on MacOS as well as on all other iOS based browsers (Safari, Firefox, Edge etc.) apart from Chrome iOS:

I got a weird feeling that "history.replaceState" might not be the only way for this uXSS to work.. But I am not an expert ;)

Anyways.. Don't forget that this bug also allows for unrestricted open redirection on all domains as well.. Long story short, thanks to this I was able to find 4 XSS on *, yet guys said that those are not valid bugs as it's a browser bug in relation to open redirection..
Example: Some data URL is being controlled..;

Let me know if I can help you in any way.. :)

Just to clarify comments #13 and #16. The workaround is to crash only if URL's password or username contains the origin of the previous URL. The crash is targeted specifically for this vulnerability and should not affect legitimate web sites. 

Comment 19 by, May 10 2018

I guess this solution should do the trick..
Also XHR request takes a while too.. might be even longer than iframe + innerHTML to it.
Thanks Tomasz! I don't think Chrome can do better than crashing. The real fix should be done in WebKit.
Eugene, can you make sure the radar has the Safari info in it? That's our best avenue to getting apple to pay attention. 
Updated rdar://
Continuing the conversation from

If (_documentURL.GetOrigin() != newURL.GetOrigin()) inside URLDidChangeWithoutDocumentChange, isn't that *alone* enough to indicate that we're in an exploitable situation? Is there any scenario in which having a document's origin mismatch the URL's origin isn't a vulnerability?
|If (_documentURL.GetOrigin() != newURL.GetOrigin())| is more broad than the check in the CL. _documentURL detection in Chrome is not 100% reliable and using more broad check can lead to crashes during legitimate navigations (so yes, there are scenarios when _documentURL may be incorrect for a brief period of time). We working on refactoring navigation stack to improve _documentURL detection.

CC a couple of Apple security folks.

The bug is seems to be an error in URL parsing. Within WebKit, ";..;" is parsed correctly into the following parts:
- host: ""
- path: "/..;..;"
- user: ""
- password: ""

However, when this URL is sent to the network layer, the data returned is from So I suspect the error happens when the URL is serialized in the WebKit -> NetworkProcess IPC, and when reparsed, it is interpreted differently.

Maybe WebKit should escape ";" and "@" when processing replace state URLs. This seems to be what happens when ";..;" is entered directly into the address bar in iOS Safari.

Does anyone know what Blink does?

Comment 26 by, May 15 2018

Tracking internally at Apple as: <rdar://problem/40258457>

Project Member

Comment 27 by, May 15 2018

The following revision refers to this bug:

commit ba1815a412382038e41adc189134fcb1b75784aa
Author: Eugene But <>
Date: Tue May 15 17:12:35 2018

Crash on unexpected URL change.

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

Labels: Merge-Request-67
Status: Fixed (was: Assigned)
Project Member

Comment 29 by, May 15 2018

Labels: -Merge-Request-67 Merge-Review-67 Hotlist-Merge-Review
This bug requires manual review: Less than 10 days to go before AppStore submit on M67
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot
Should we leave this open as ExternalDependency, since we probably want to remove the force-crashing when Apple fixes the bug for real? That, or file a new bug to track it.
Can we get unit tests please? Also how confident are you in this fix, Eugene?
Status: ExternalDependency (was: Fixed)
Marking as ExternalDependency, because the code references this bug.

No, we can not write unit tests which verify that the app crashes. This is a risky fix which can introduce new crashes, but the change is behind the flag which can be turned off  on the server. Given the severity of this bug I believe we have to merge this to M67 per Security_Severity-High SLA.
Labels: -Hotlist-Merge-Review -Merge-Review-67 Merge-Approved-67
Approving per the high security severity and the fact that the change is behind a flag. Please merge asap.
Project Member

Comment 35 by, May 15 2018

Labels: -merge-approved-67 merge-merged-3396
The following revision refers to this bug:

commit 763ba59928da808a9b3f0da1ac777122f33507d3
Author: Eugene But <>
Date: Tue May 15 20:44:48 2018

Crash on unexpected URL change.

(cherry picked from commit ba1815a412382038e41adc189134fcb1b75784aa)

Bug:  841105 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I4471a98cdef13e54b790ebcd565d59c67dba8bfd
Reviewed-by: Rohit Rao <>
Reviewed-by: Danyao Wang <>
Commit-Queue: Eugene But <>
Cr-Original-Commit-Position: refs/heads/master@{#558760}
Reviewed-by: Eugene But <>
Cr-Commit-Position: refs/branch-heads/3396@{#609}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}

Owner: ----
Project Member

Comment 37 by, May 16 2018

Status: Fixed (was: ExternalDependency)
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit - Your friendly Sheriffbot
Labels: -ReleaseBlock-Stable
Project Member

Comment 39 by, May 17 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Status: Verified (was: Fixed)
Verified in M67.0.3396.57 beta
iOS: 11.4 beta#6, 11.3.1, 11.2.6
Devices: iPhoneX, iPad Pro, iPhone8

App crashes as soon as the test URL from initial report is opened.
Labels: Release-0-M67
Labels: CVE-2018-6128 CVE_description-missing
Status: Assigned (was: Verified)
Re-opening this bug.  eugenebut@ can explain why.
The workaround had non-trivial amount of false positive crashes. We will disable the workaround in M67 with Finch kill switch until we deal we those crashes.
Labels: -reward-topanel reward-unpaid reward-7500
*** 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.
Congratulations thomi@! The Chrome VRP panel decided to award $7,500 for this report.

Note that we usually only reward once the bug has been fixed, and this one just reopened, but in this case I'm going to process it now anyway.

Labels: -reward-unpaid reward-inprocess
Status: Verified (was: Assigned)
We fixed false positive crashes and shipped refresh build to AppStore. Finch kill switch was not used.
Project Member

Comment 54 by, Sep 12

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