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

Issue 650498 link

Starred by 8 users

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Extension stylesheet resources fail to bypass page CSP

Reported by co...@streak.com, Sep 27 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Steps to reproduce the problem:
1. Have a web page which uses a Content-Security-Policy header restricting image sources.
2. Have an extension which inside a content script injects a <link rel="stylesheet" ...> element into the page:

    var style = document.createElement('link');
    style.rel = 'stylesheet';
    style.type = 'text/css';
    style.href = 'https://.../injected.css';
    document.head.appendChild(style);

3. Any images that stylesheet includes may be blocked by CSP: "Refused to load the image 'https://.../....png' because it violates the following Content Security Policy directive: "..."."

For example, download https://crashcoherency.net/misc/exttest/test.zip, extract it, load it as an unpacked extension, and go to https://crashcoherency.net/misc/exttest/ to see the above issue.
(This example extension also demonstrates Issue 392338 and Issue 408932.)

What is the expected behavior?
The image should not be blocked, since extensions should be able to bypass the page's CSP.

What went wrong?
Chrome allowed the stylesheet itself to load, bypassing the page's CSP, but it didn't give the same treatment to images that the stylesheet referenced.

WebStore page: 

Did this work before? No 

Chrome version: 53.0.2785.116  Channel: stable
OS Version: OS X 10.11.4
Flash Version: 

Some previous discussion of this and other extension CSP issues took place in  Issue 391128 .
 
Project Member

Comment 1 by sheriffbot@chromium.org, Sep 27 2017

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 2 by co...@streak.com, Sep 27 2017

This issue still exists; just tested with Chrome Version 62.0.3202.29 (Official Build) beta (64-bit).
Cc: devlin@chromium.org
Status: Unconfirmed (was: Archived)
Hey Devlin, could you take a look at this to see whether this is something that we'd support.
Cc: sc00335...@techmahindra.com
Labels: Triaged-ET M-63 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on reported version 53.0.2785.116, on latest stable 61.0.3163.100 and on latest canary 63.0.3233.0 using Mac 10.12.6,Ubuntu 14.04 and Windows 10 with steps mentioned in comment#0. 

Same behaviour is seen from M50[50.0.2661.54]. Hence considering this as Non-regression and marking as Untriaged.
Owner: mkwst@chromium.org
Status: Assigned (was: Untriaged)
This is interesting.  At first glance, this seems pretty reasonable (extensions should be able to bypass CSP, and it works for the stylesheet).  However, my guess is that we don't track that the stylesheet was added by an extension, and anything the stylesheet itself does is subject to the page's CSP.  In some ways, this is similar to what we do for scripts - any script added by an extension via a <script> tag will run in the main world, and will have all the privileges and constraints of the page.  And for scripts, that's largely WAI.

mkwst@, I think you worked on a lot of the CSP for extensions in blink; WDYT here?

Sign in to add a comment