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

Issue 792836 link

Starred by 2 users
Status: Duplicate
Merged: issue 515309
Owner:
creis@chromium.org
Closed: Dec 2017
Cc:
█ nick@chromium.org
creis@chromium.org
alex...@chromium.org
█ nasko@chromium.org
wfh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature

Blocking:
issue 786673



Sign in to add a comment

Site isolation: verify Origin header in requests coming from renderers

Project Member Reported by fr...@google.com, Dec 7 2017 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
N/A

What is the expected behavior?
A compromised renderer can currently fake any HTTP request, including the Origin header. Site isolation brings forward the possibility to filter out requests which present a wrong Origin.

What went wrong?
N/A

Did this work before? N/A 

Chrome version:   Channel: stable
OS Version: 
Flash Version:

Comment 1 by nasko@chromium.org, Dec 7 2017

Blocking: 786673
Cc: creis@chromium.org nick@chromium.org nasko@chromium.org alex...@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: OS-Android OS-Chrome OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)

Comment 2 by creis@chromium.org, Dec 7 2017

Mergedinto: 515309
Owner: creis@chromium.org
Status: Duplicate (was: Untriaged)
Yep!  There's already a start for this in  ChildProcessSecurityPolicyImpl::CanSetAsOriginHeader.  We've got a bug on file to add site isolation enforcement in issue 515309.
►

Sign in to add a comment