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

Issue 726178 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
a...@google.com
█ mkwst@chromium.org
jam@chromium.org
clamy@chromium.org
creis@chromium.org
lukasza@chromium.org
alex...@chromium.org
carlosk@chromium.org
█ nasko@chromium.org
wfh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 721329
Blocking:
issue 786673



Sign in to add a comment

PlzNavigate: URLs are potentially disclosed across cross-origin renderers via mixed content IPCs

Project Member Reported by alex...@chromium.org, May 25 2017 
This is a variant of  issue 718942  for mixed content IPCs.  If we've got https://a.com/sensitive.html, which embeds an insecure subframe http://b.com, the browser-side mixed content check will send a FrameMsg_MixedContentFound to b.com which, IIUC, contains the full https://a.com/sensitive.html URL in params.main_resource_url.  It also will contain the source location of the navigation from a.com in params.source_location if you patch in Arthur's WIP CL (https://codereview.chromium.org/2901223003/) to fix  issue 690946 .  As in  issue 718942 , we should not be disclosing that information to a potentially separate, cross-origin renderer.

Currently, the problematic URL and source location are only used for a console message.  FrameMsg_MixedContentFound also sometimes triggers a CSP strict mixed content violation report (for block-all-mixed-content), but that doesn't use those URLs.  This is another issue that could be solved by directly routing console messages to the devtools process (see issue 721329).

One example repro of this is the layout test http/tests/security/mixedContent/insecure-iframe-in-iframe.html with --enable-browser-side-navigation and --site-per-process.

I'll assign this to myself for now, since arthursonzogni@ is OOO for the next couple of days.

Comment 1 by jam@chromium.org, May 30 2017

Cc: jam@chromium.org
Labels: -Proj-PlzNavigate-Blocking
From Charlie in email 

"I talked with alexmos@ about the mixed content / CSP issue, and it's a data leak between renderer processes.  However, it probably shouldn't be a launch blocker because it mainly affects --site-per-process.  I don't think it affects Isolate Extensions mode.  (?)"

Until someone confirms that it affects isolate extensions, I'm going to remove the plznavigate-blocking flag.

Comment 2 by alex...@chromium.org, Jun 13 2017

Cc: -arthurso...@chromium.org alex...@chromium.org
Owner: arthurso...@chromium.org
I'll hand this back to Arthur.  I think the plan we agreed on was to see if we can take care of this without reducing the quality of mixed content console messages by fixing issue 721329.  I agree that this shouldn't affect --isolate-extensions and so it's not a blocker for PlzNavigate.

Comment 3 by creis@chromium.org, Nov 18 2017

Blocking: 786673

Comment 4 by nasko@google.com, Dec 19

Labels: -Pri-1 Pri-3
arthursonzogni@, do you plan on working on this bug? If not, might be a good idea to unassigned it and make it available, so others could potentially consider looking at fixing it?

Also, changing from P1, since it doesn't strike me as really that important if it hasn't been touched for more than an year.

Comment 5 by arthurso...@chromium.org, Dec 19

Blockedon: 721329
Owner: ----
Status: Available (was: Assigned)
To fix this, we need to work on issue 721329. Making possible to send console error's to devtools without going through a potentially compromised renderer process.
Removing myself from this bug.

Comment 6 by a...@google.com, Jan 11

Cc: a...@google.com
►

Sign in to add a comment