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

Issue 796968 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
alex...@chromium.org
█ nasko@chromium.org
wfh@chromium.org
creis@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 786673



Sign in to add a comment

Enforce no localStorage access from sandboxed frames

Project Member Reported by lukasza@chromium.org, Dec 21 2017 
AFAIK, currently sandboxed frames (and unique origins in general) are not isolated from their parent.  Since a non-sandboxed parent and a sandboxed child are hosted in the same renderer process, we can't grant or deny access to origin-bound data based on the renderer process id available when handling an IPC (e.g. when handling StoragePartitionImpl::OpenLocalStorage).

From another angle - AFAIK, currently denying access for unique origin depends on renderer-side checks.

(this bug is a follow-up for the discussion at https://chromium-review.googlesource.com/c/chromium/src/+/769647/15/content/browser/frame_host/render_frame_host_impl.cc#3272)

Comment 1 by lukasza@chromium.org, Dec 21

Cc: nasko@chromium.org
+nasko@ who works on precursor origins

For some enforcements (like RFHI::CanCommitOrigin) we should allow opaque origins, as long as their precursor origin matches the process lock.  OTOH, for other enforcements (like sessionStorage) opaque origins should be disallowed altogether.

Comment 2 by lukasza@chromium.org, Dec 21 

I think that the current bug has 2 aspects to it:

1. Isolating opaque origins into a separate process.  This aspect is orthogonal to the isolation-enforcement-against-compromised-renderers (issue 786673).

2. Enforcing certain aspects of opaque origins on the browser side (e.g. rejecting opaque origin if its precursor doesn't match the process lock).  This aspect is indeed related to issue 786673.
►

Sign in to add a comment