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

Issue metadata

Status: Fixed
Closed: Oct 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Redirect to chrome:// URIs via Location: header

Reported by, Sep 4 2011 Back to list

Issue description

Usually, Google Chrome don't allow redirect to chrome:// URIs.

For example,

<meta http-equiv="refresh" content="0;url=chrome://about">



don't redirect.

But Location: header is different.
I could redirect to "chrome://about" via following header.


I think this behavior is bad.

Chrome Version: 13.0.782.220 stable
Operating System: Windows Vista sp2
Labels: -Pri-0 -Area-Undefined Pri-2 Area-Internals SecSeverity-Medium
Status: Available
I just tested, and the redirect does work. The DOMUI process restrictions prevent settings manipulation, and same-origin prevents the data from getting read by a web site. So, it does seem to be pretty well mitigated, but we really shouldn't be allowing it regardless.

(Adding in some people who might have a quick pointer on what's going on here.)

Comment 2 by, Sep 8 2011

This looks fairly easy to diagnose: renderer checks the scheme for meta refresh and JS redirects against WebSecurityPolicy, but this doesn't apply to HTTP redirects because they are handled at a different layer. I don't know, but might this be intentional because it doesn't have the same security implications?

It might be simple to change this, URLRequestHttpJob::IsSafeRedirect looks like a reasonable place to start.
Status: Assigned
There are security implications. A web page must never be able to redirect to chrome:// under any circumstances. We've had really unpleasant XSS there in the past. Tom's CSP work should cut down on that, but still...

Fancy tackling it? :)

Comment 4 by, Sep 8 2011


Comment 5 by, Sep 9 2011

This is turning out to be tricky. about://* and chrome://* internally use a lot of chrome: redirects, so it would appear that blocking them in ChildProcessSecurityPolicy breaks several things that some people might consider important (like chrome://settings).

At this point it looks like we want to do something like allowing chrome:// redirects conditionally based on the origin of the redirect, but this is sounding complicated and easy to get wrong, so I'm soliciting feedback.

Does anyone in the cc: line have any thoughts on how to address this bug?

Comment 6 by, Sep 12 2011


There is a simple change to URLRequestHttpJob that looks like it fixes the issue without any undesirable side effects:

I'd like feedback from someone in net/OWNERS if this would be acceptable. I haven't written a unit test because this might be too hacky, but other approaches have some significant trade-offs also.

Another possibility would be to try to do this in WebKit, because it does some processing of HTTP redirects. If it denied redirects based on a check to SecurityOrigin::canDisplay() then this would resolve the issue, but would also change behavior in other browsers. I don't know whether or not this would cause problems.
Status: Started

Comment 9 by, Sep 23 2011

Upstreamed to WebKit as:

Comment 10 by, Sep 27 2011

Labels: OS-All

Comment 11 by, Sep 28 2011

Labels: Mstone-15
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Merge-Approved
Status: FixUnreleased
Landed upstream.

Committed r96610: <>
Labels: SecImpacts-Stable
Batch update: Guessing based on search criteria that this security bug impacted a stable release.
Labels: -Merge-Approved Merge-Merged merge-merged-874
merged to m15 in r96957
Labels: CVE-2011-3879

Comment 16 by, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 17 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 18 by, Mar 10 2013

Labels: -Type-Security -Area-Internals -SecSeverity-Medium -Mstone-15 -SecImpacts-Stable M-15 Security-Severity-Medium Cr-Internals Security-Impact-Stable Type-Bug-Security
Project Member

Comment 19 by, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 20 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 22 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 23 by, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Labels: reward-topanel
Project Member

Comment 25 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 26 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: -reward-topanel reward-unpaid reward-2337
We're going over old bugs that might have missed going in front of the VRP panel.  The panel decided to award $1,000 for this bug, plus an additional $1337!
Labels: -reward-unpaid reward-inprocess
Labels: CVE_description-submitted

Sign in to add a comment