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

Issue 634265 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: chrome.webRequest extension API should not allow tampering Content-Security-Policy header

Reported by alexandr...@gmail.com, Aug 4 2016

Issue description

VULNERABILITY DETAILS

VERSION
Chrome Version: 51.0.2704.84 (Official Build) (64-bit)
Operating System: Mac OS X 10_11_5

DESCRIPTION
Any extension can modify or completely remove Content-Security-Policy header specified by a web site by using chrome.webRequest API

WHY IT IS BAD
First, it violates W3C recommendation https://www.w3.org/TR/CSP2/#security-considerations "The Content-Security-Policy header ... SHOULD NOT be modified or removed by proxies or other intermediaries not in the same administrative domain as the resource."
Second, Content-Security-Policy is designed to let site owners take control over what code is executed on the client side. 
Ad injectors and malicious extensions are a big problem. Google estimates 5.5% users have ad injectors. 
Content-Security-Policy could be a perfect instrument to stop malicious extensions by limiting script-src and blocking injected scripts. However, this approach can be easily bypassed in Chrome.

PROPOSED SOLUTION
Have a blacklist of critical headers (including Content-Security-Policy and Content-Security-Policy-Report-Only) that extensions cannot access thru webRequest API.
If a web app wants to allow some particular extension, it can explicitly state this in its policy, e.g. Content-Security-Policy: default-src chrome-extension://someid

PROOF OF CONCEPT
The following code will remove CSP header from all responses

chrome.webRequest.onHeadersReceived.addListener(function(details){
	var newResponseHeaders = [];
	for (var i = 0; i < details.responseHeaders.length; i++) {
		var isCSPHeader = /content-security-policy/i.test(details.responseHeaders[i].name);
		if (!isCSPHeader) {
			newResponseHeaders.push(details.responseHeaders[i]);
		}
	}
	
	return {
		responseHeaders: newResponseHeaders
	};
}, {
	urls: ["<all_urls>"],
	types: ['main_frame']
}, ['blocking', 'responseHeaders']);
 
Cc: mkwst@chromium.org
Components: Platform>Extensions>API Blink>SecurityFeature
Labels: Security_Severity-Low Security_Impact-Stable OS-Chrome OS-Linux OS-Mac OS-Windows Pri-2
Owner: mea...@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report! 

meacer/mkwst: could you please take a look and comment whether this is WAI or if there is something we should fix? Thanks!

I would argue this is not a security bug, as it doesn't violate the spec so we may want to re-categorize. 
"Content-Security-Policy could be a perfect instrument to stop malicious extensions by limiting script-src and blocking injected scripts."

This isn't fully accurate, Chrome's priority of constituents is user > web site > browser. This means an extension installed by and acting on behalf of the user can circumvent measures put by websites.

However, there are indeed a number of headers that would be nice to be blacklisted from being tampered by webRequest. That work is being tracked at crbug.com/158073.

Comment 3 by mkwst@chromium.org, Aug 5 2016

https://www.w3.org/TR/CSP3/#extensions is relevant here.

Basically, we model extensions more or less as an application of the user's will, and, as meacer@ notes, we prioritize the user above the site. This means that the extension is explicitly allowed to do things that the site owner would prefer that it not do. If we're going to have a meaningful extension system, then I think that needs to be the stance we take.

Comment 4 by mea...@chromium.org, Aug 11 2016

Status: WontFix (was: Assigned)
Closing the bug based on earlier comments.
Labels: -Restrict-View-SecurityTeam
 Issue 641750  has been merged into this issue.

Comment 7 by mea...@chromium.org, Oct 21 2016

Labels: -Security_Severity-Low -Security_Impact-Stable

Comment 8 by mea...@chromium.org, Oct 21 2016

Labels: allpublic

Sign in to add a comment