Security: chrome.webRequest extension API should not allow tampering Content-Security-Policy header
Reported by
alexandr...@gmail.com,
Aug 4 2016
|
|||||
Issue descriptionVULNERABILITY 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']);
,
Aug 5 2016
"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.
,
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.
,
Aug 11 2016
Closing the bug based on earlier comments.
,
Sep 8 2016
,
Sep 8 2016
Issue 641750 has been merged into this issue.
,
Oct 21 2016
,
Oct 21 2016
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by raymes@chromium.org
, Aug 5 2016Components: 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)