Content Security Policy restrictions workaround #1263

Open
wants to merge 1 commit into
from

Projects

None yet

6 participants

@termi
termi commented Mar 12, 2014

fixes #1262

@patrickkettner patrickkettner commented on the diff Mar 12, 2014
src/setCss.js
*/
- function setCss( str ) {
- mStyle.style.cssText = str;
+ function setCss( node, str ) {
+ try {
+ node.style.cssText = str;
+ }
+ catch(e) {// Content Security Policy restrictions workaround
+ node.setAttribute('style', str);
@patrickkettner
patrickkettner Mar 12, 2014 Member

is there a reason we wouldn't just set the .style attr all the time?

@termi
termi Mar 12, 2014

Setting .style attr all the time can affect anything else

@patrickkettner
patrickkettner Mar 12, 2014 Member

Sorry, I don't understand, could you rephrase?

@termi
termi Mar 12, 2014

setting the 'style' attribute, regardless of whether or not CSP is on, can break some feature detections in some random browser.

@patrickkettner
patrickkettner Mar 12, 2014 Member

I totally get that it may break, however we are doing it here already. plus you are catching anonmous errors all over the place, which would result in the tests being inaccurate. I think the best thing to do would be to change it all to style, and run the whole thing through the browserstack suite of supported browsers to see if it breaks anywhere

@SlexAxton
Member

Doesn't this just fix 'unsafe-eval' and not 'unsafe-inline'? Are there a lot of people that are blocking one and not the other? I believe the attack vector is the same in both cases, you just need to inject selectors when injecting style sheets.

@ceram1
ceram1 commented Apr 5, 2014

Maybe this issue can be fixed by changing some functions.

Like..

// Check for css support
function checkCssSupport(property) {
var body = document.body || document.documentElement, style = body.style;

// No css support detected
if (typeof style == 'undefined') {
    return false;
}

// Tests for standard prop
if (typeof style[property] == 'string') {
    return true;
}

// Tests for vendor specific prop
var v = [ 'Moz', 'Webkit', 'Khtml', 'O', 'ms', 'Icab' ];
property = property.charAt(0).toUpperCase() + property.substr(1);
for (var i = 0; i < v.length; i++) {
    if (typeof style[v[i] + property] == 'string') {
        return true;
    }
}

return false;

}

From
https://gist.github.com/jackfuchs/556448

@RehanSaeed

Cross Post From StackOverflow.

I am attempting to use the new Content Security Policy (CSP) HTTP headers on a test site. When I use CSP in conjunction with Modernizr I get CSP violation errors. This is the CSP policy I am using:

Content-Security-Policy: default-src 'self'; script-src 'self' ajax.googleapis.com ajax.aspnetcdn.com; style-src 'self'; img-src 'self'; font-src 'self'; report-uri /WebResource.axd?cspReport=true

These are the errors from the Chrome browser console:

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self'". 
Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.

window.Modernizr.injectElementWithStyles   - modernizr-2.7.2.js:134
window.Modernizr.tests.touch               - modernizr-2.7.2.js:457(anonymous function)
modernizr-2.7.2.js:949(anonymous function) - modernizr-2.7.2.js:1406

This workaround was first put forward in March, is there no more progress in getting this issue resolved. There is a comment in the StackOverflow question in which someone suggests taking a look at AngularJS as they have full support for CSP.

I know that I can include the unsafe-inline directive which can get around this error but this also enables unsafe code to run and negates the use of CSP in the first place. Does anyone have any solutions.

@mattbostock mattbostock added a commit to mattbostock/leavediary that referenced this pull request May 11, 2015
@mattbostock mattbostock Allow export and sync to calendar
Allow the export of an ICS vCalendar file based on RFC 2445.

The vCalendar file is also accessible via a private URL unique to each
job a user has, such that services such as Google Calendar can
'subscribe' to a user's leave calendar.

The `script-src` and `style-src` modifications in the Content Security
Policy header in `main.go` are necessary to support the modular pop-up
when clicking the 'Add to calendar' link with Javascript enabled.

Specifically, `script-src` uses a hash to match the
`$(document).foundation();` call at the base of the HTML page and
`style-src` allows inline styles, which is currently necessary to
support modernizr.js as used by the Foundation framework:

Modernizr/Modernizr#1263
Modernizr/Modernizr#1450
a446be7
@quinncomendant

What is the status of this fix? I too am trying to find a solution to using Modernizr with CSP.

@RehanSaeed

+1

@quinncomendant

FYI This is being discussed in issue #1262

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment