Issue metadata
Sign in to add a comment
|
Referrer leak when Chrome Web App is installed on a path |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. Go to http://www.example.com 2. Execute the following JS in the developer console ` win = window.open('', '_blank', '') win.opener = null; win.document.write('<META HTTP-EQUIV="refresh" content="0; url=https://www.whatismyreferer.com/">') win.document.close(); ` 3. You will be navigated to a new page. Confirm that the referrer did not leak here. This is expected. 4. Install an extension in developer mode with the following manifest file: { "name": "Example App", "version": "0.0.0.1", "manifest_version": 2, "app": { "urls": [ "http://www.example.com/" ], "launch": { "web_url": "http://www.example.com/" } } } 5. Go back to http://www.example.com and run the snippet from step 2 again. 6. Observe that the referrer from the current page has been leaked. What is the expected behavior? What went wrong? Chrome unexpectedly leaks the referrer from pages in certain situations. Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: Flash Version: This behavior breaks the Closure library's mechanism for referrer header stripping in https://github.com/google/closure-library/blob/master/closure/goog/window/window.js#L222
,
Dec 3 2017
Assigning low severity based on the fact that an extension needs to be installed for this to work. Though thinking more this is really more of a privacy issue. Is this a situation where the referrer should not be revealed?
,
Dec 4 2017
+Nasko and Alex for navigation expertise.
,
Dec 4 2017
I'm attaching the extension described in Step 4. Note this extensions contains just the single file `manifest.json`. The observed header value from Step 6 should be "http://www.example.com/". Can you reproduce based on this info? Note that the referrer is ordinarily hidden but is revealed when the extension is installed, and that this breaks the referrer hiding functionality in the Closure library.
,
Dec 7 2017
,
Dec 7 2017
Are you able to repro this?
,
Dec 16 2017
I can confirm that this repros on trunk. Opening the window from the app and navigating it cross-site like this will swap processes in default Chrome, but the cross-process navigation is not the cause here, as this doesn't repro without the app but with --site-per-process. +mkwst@ and estark@ for referrer expertise: is there anything special we do for referrers based on whether we are navigating from an app?
,
Dec 16 2017
,
Jan 25 2018
,
Mar 6 2018
ping on this
,
Mar 6 2018
why is closure using this strange dance to strip the referrer instead of just using a referrerpolicy attribute on a link?
,
Mar 7 2018
I'm guessing the original code was written long ago, before referrerpolicy was available.
,
Mar 7 2018
,
Mar 21 2018
,
Mar 22 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/667bbc393243d9d45415f036130b0ec2ef9f69bb commit 667bbc393243d9d45415f036130b0ec2ef9f69bb Author: Jochen Eisinger <jochen@chromium.org> Date: Thu Mar 22 21:16:13 2018 Check content fork policy before asking the embedder. Otherwise, installing an app on a domain that tries to fork will break this behavior due to the extensions triggered process switch. BUG= 791216 Change-Id: I2b75331b760224fb5524808be8cac9ae5a293a4c Reviewed-on: https://chromium-review.googlesource.com/973224 Commit-Queue: Charlie Reis <creis@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Cr-Commit-Position: refs/heads/master@{#545250} [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/browser/cross_site_transfer_browsertest.cc [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/renderer/render_frame_impl.cc [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/shell/common/shell_switches.cc [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/shell/common/shell_switches.h [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/shell/renderer/shell_content_renderer_client.cc [modify] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/shell/renderer/shell_content_renderer_client.h [add] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/test/data/echo-referrer.html [add] https://crrev.com/667bbc393243d9d45415f036130b0ec2ef9f69bb/content/test/data/fork-popup.html
,
Mar 23 2018
,
Mar 24 2018
,
Jun 29 2018
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 |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Dec 2 2017