I use the Webflow tool to set up my website. I export the code to host it on my server.
I have set up the Content-Security-Policy header.
Problem : most of the styles are inline. I can't add the hash for all of them, there are too many ...
Is it so dangerous to put unsafe inline on style-src ?
Note that this is a 99.9% static site (just a contact form).
Thank you for your help!
The dangers of 'unsafe-inline' in style-src are discussed here: https://scotthelme.co.uk/can-you-get-pwned-with-css/
If you can restrict the rest of your CSP, the dangers will be limited, but there will always be someone who disagrees. If it is technically possible you could use nonces, as you could use the same nonce for all tags, but change it on every pageload. It seems like you don't want or can extract all the CSS to a separate file, which would of course be the simplest solution.
Related
Trying to set a decent CSP policy for a multi-tenant webapp.
Since users can add content themselves, whitelisting or blacklisting certain domains is impossible.
It is possible to white list the default src's the app itself is using, but for other resources, it must be a wildcard, for example -
Content-Security-Policy: default-src 'self' trusted.com *.trusted.com ; img-src *; media-src *; script-src *; object-src *; font-src *; style-src *; frame-src *
I guess the actual question is - would it be efficient to set up such a CSP header versus not setting one at all?
If your users can add their own javascript as content by design, your application is vulnerable to XSS anyway. If they can't, then you should remove script-src * and replace maybe with self. This would help prevent some XSS attacks which should probably be your most important concern.
The same applies to object-src, does that need to be * too? It shouldn't be. The rest of the * values are I think present less risk, modern browsers will not normally run javascript from those.
The third thing that comes to mind is clickjacking. Do these pages ever have to be displayed in a frame? If no, then it's easy, you could set frame-ancestors to none, or self if you use iframes on your own origin. If your users do want to embed their page in an iframe, you could for exmaple have them register their origin when they want to have the iframe, and your application could dynamically generate a suitable frame-ancestors csp based on the origin of the current request.
I am trying to use a hash with my content security policy...
Below are two example errors in my console:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' apis.google.com cdn.iubenda.com cdnjs.cloudflare.com www.googletagmanager.com". Either the 'unsafe-inline' keyword, a hash ('sha256-oKmCrr+GWRARSXYeVJshOWETr0oqOtt73CNO8efpujQ='), or a nonce ('nonce-...') is required to enable inline execution.
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' apis.google.com cdn.iubenda.com cdnjs.cloudflare.com www.googletagmanager.com". Either the 'unsafe-inline' keyword, a hash ('sha256-pS4Uy3ilo+JLn8IadtJGfyO9z7jqIrGUONfEUDLxoPk='), or a nonce ('nonce-...') is required to enable inline execution.
Here is the corresponding content security policy directive:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' apis.google.com cdn.iubenda.com cdnjs.cloudflare.com www.googletagmanager.com; style-src 'self' fonts.googleapis.com; img-src 'self' cdn.shortpixel.ai secure.gravatar.com; font-src 'self' fonts.googleapis.com fonts.gstatic.com";
Specifically in this example:
script-src 'self' apis.google.com cdn.iubenda.com cdnjs.cloudflare.com www.googletagmanager.com;
From what I gathered from reading the CSP guide on hashes, I should be able to add the hash as per my console to the directive...
The easiest way to generate it is to just open the developer tools console and it will output what the expected hash of your script was in the console error message.
But if I modify my directive to include the hash (example below), I still get the same error in console (obviously with a different hash).
script-src 'self' apis.google.com cdn.iubenda.com cdnjs.cloudflare.com www.googletagmanager.com 'sha256-oKmCrr+GWRARSXYeVJshOWETr0oqOtt73CNO8efpujQ=';
How exactly is the correct way to hash a CSP directive? And why are there multiple errors for the same directive, is this basically one for each domain specified? Should one hash cover all the domains specified?
Not really sure how I should be doing this.
From what I gathered from reading the
content-security-policy.com/hash/ CSP guide on hashes, I should be
able to add the hash as per my console to the directive...
Yeah, it's working only "theoretically", the "practice" is more hard. Yes, Google Chrome calcs hashes, but you need to read the error message carefully to determine what is really blocked: inline script, javascript: navigation or inline event handler. Because each of these have own way how to fix.
- Inline scripts can be just allowed by 'sha256-VALUE' token.
- to allow javascript: navigation and inline event handlers you need to use 'sha256-VALUE' tokens with 'unsafe-hashes'. And not all browsers support 'unsafe-hashes' for javascript: navigation as for now.
But if I modify my directive to include the hash (example below), I
still get the same error in console (obviously with a different hash).
Why do you stopped? I see you use www.googletagmanager.com (GTM), do you think GTM has only one inline script? You allowed the parent script, it began to load the child ones, so you need hashes for both.
You can use parent script hash + 'strict-dynamic' token to allow all the childs ones, but it does not work in Safari as for now.
At the final you will get a lot of hashes for all inline scripts. Bad thing is that GTM and others can time to time change content of it inline scripts, so you have to add a new hashes and to remove obsoletes. But you don't know which hash to which script belongs.
Therefore the preferable way is to use 'nonce-value' for any inline scripts, all the more since GTM distributes 'nonce' to all inline scripts except Custom HTML Tags. For Custom HTML Tags(if used) you can use hashes, because those scripts is under your control.
It's better to investigate all inline scripts manually before decide how it easier and reliable way to allow them.
PS: GTM is a hard nuts for CSP because GTM can be used to inject a open list of inline/external scripts. And if use the custom JavaScript variable names are used for the «Custom HTML tag», it required to allow 'unsafe-eval'.
You can test your GTM ID for what additional scripts it loads and which CSP is enough for it.
I have a CSP with the following line in it:
script-src 'nonce-{random}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http: https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js;
and I can see that the CSP is correct in the response header for the page.
I am still getting a [Report Only] Refused to load the script https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js error.
Cloudflare is auto-injecting this script tag and so I cannot rely on the strict-dynamic property to cover it for me, nor can I add a nonce.
Is this failing because of scrict-dynamic overriding the fixed url in the CSP? We need strict-dynamic within the app, but we also need to allow a custom whitelist url for these situations.
Any ideas?
Edit: Specifically I think the issue is cloudflare here. How is it possible to allow cloudflare to inject scripts, while at the same time having strict-dynamic set? You cannot give cloudflare a nonce, and strict-dynamic will not let you white-list so how is it possible to overcome this?
If you use strict-dynamic, it ignores the allow-listed domain. That's why that approach isn't working.
BTW, you can't use a full URL like http: https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/email-decode.min.js anyway. You can only use https://static.cloudflareinsights.com https://mydomain.app/cdn-cgi/scripts/6c4dd986/cloudflare-static/.
BTW, you may find https://csp-evaluator.withgoogle.com/ helpful for finding problems like that in your CSP. (I'm not affiliated with them. I just think it's useful.)
At the end of the day, Cloudflare is going to need to fix this on their side. They see your CSP in your response. They need to make use of your nonce. They do this sometimes. If you read https://developers.cloudflare.com/bots/reference/javascript-detections/, it says, "If your CSP uses a nonce for script tags, Cloudflare will add these nonces to the scripts it injects by parsing your CSP response header."
We want to secure our site with Content-Security-Policy, and even with the setting of allowing inline scripts (default-src 'self'; script-src 'self' 'unsafe-inline'), loading modernizr (2.6.2) produces 4 CSP violations:
I upgraded to the latest version (3.6.0), the develop version, and now it produces over 30 CSP violations:
I couldn't find any official statement on CSP on the modernizr site, it merely mentions that in 2012, they added a detect for Content Security Policy (https://modernizr.com/news/modernizr-262).
Reading various blogs and Stack Overflow questions, I find most up-to-date best-practice from 2017 to be:
If modernizr is injecting all that inline stuff than it seems like
your choices are to either (a) add all those hashes, (b) use
'unsafe-inline' (but which basically defeats the whole purpose of
CSP…), or (c) don’t use modernizr.
Although, the errors I am getting occur even when using unsafe-inline.
Has anyone found a workable solution to using both Content-Security-Policy and modernizr?
Try using this lenient CSP default-src * 'unsafe-eval' 'unsafe-inline' 'unsafe-dynamic' data: filesystem: about: blob: ws: wss: and start removing keywords until you start getting errors, with this method you can adjust your CSP to your needs.
It would be nice if there was some sort of CSP generator where you give it a website and it just knows which CSP you need in order to not keep erroring.
Remember that * means allow all domains, so replace this with all domains you intent to support.
This of course just fixes, or solves the issue, and it depends what it's at stake, what content does your website offer, and how vulnerable would users be if an XSS attack could be carried through. CSP protects merely against XSS attacks, this is just JavaScript that could be inserted by a third party, using HTTPS for example, will make it almost impossible for a MITM to inject arbitrary code.
In CSP v2 frame-src was deprecated. child-src is recommended to use instead.
In CSP v3 frame-src in undeprecated and child-src is deprecated.
Currently (sep 2017) Chrome:
The 'child-src' directive is deprecated and will be removed in M60, around August 2017. Please use the 'script-src' directive for Workers instead.
So what's correct collection of directives to work in modern (minus 2 versions) browsers? Looks like frame-src + script-src is enough? But what should be in script-src then?
PS: is it even legal to "undeprecate" stuff?
2018-12-20 update
child-src has in the meantime been un-deprecated… So now neither frame-src nor child-src are deprecated any longer. But the guidance from the original answer here still holds true:
So what's correct collection of directives to work in modern (minus 2 versions) browsers?
It seems like the answer to that depends on what exactly you want to specify a policy for.
If your needs are simple and so you don’t want to have different policies for iframe elements and scripts, then just use default-src to specify the same policy for both.
If your needs are more complicated and you want a policy for iframe elements that’s different than the policy for other resources, than use frame-src. Similarly, if you want a policy for scripts that’s different than the policy for other resources, then use script-src.
If you don’t want a policy for worker scripts different than the policy for other scripts, then you’re fine just providing a script-src policy, and can stop there.
If you do want a policy for worker scripts different than the policy for other scripts, then along with providing a script-src policy, provide a worker-src policy too. The worker-src one won’t effect browsers yet, but will future-proof things for when browsers do add support.
See https://github.com/w3c/webappsec-csp/issues/239#issuecomment-336135344 if you’re curious about the rationale for child-src being un-deprecated:
I was hoping other vendors would implement worker-src so we could drive down usage of child-src and remove it from the platform, but it doesn't look like that's happening quickly enough (removing Chrome's weird fallbacks would break a worker load on 0.006% of page views, which is not huge, but not nothing).
2017-09-04 answer
It’s even a bit more complicated than what’s described in the question, because the CSP3 spec also introduces the worker-src directive. But the spec gives the following guidance:
The child-src model has been substantially altered:
The frame-src directive, which was deprecated in CSP Level 2, has been undeprecated, but continues to defer to child-src if not present (which defers to default-src in turn).
A worker-src directive has been added, deferring to script-src if not present (which likewise defers to default-src in turn).
child-src is now deprecated.
That’s in https://w3c.github.io/webappsec-csp/, which is an editor’s draft but is what you should always consult for current spec requirements. Reason: You can’t trust https://www.w3.org/TR/CSP/ to be up to date (and in general you can’t trust anything under https://www.w3.org/TR to be up to date), and editor’s drafts are what browser implementors actually implement from (they don’t wait to implement until something’s published under https://www.w3.org/TR).
Anyway, the reason the child-src directive was deprecated is that its effect is specified as:
The child-src directive governs the creation of nested browsing contexts (e.g. <iframe> and <frame> navigations) and Worker execution contexts.
The problem with that in practice is: an iframe is very different than a worker script. So that’s why worker-src was added and why frame-src was un-deprecated (because you really do want a separate directive to specify policies for iframe elements), and why child-src was deprecated (because you really don’t want to apply one policy to both iframe elements and worker scripts).
So what's correct collection of directives to work in modern (minus 2 versions) browsers?
It seems like the answer to that depends on what exactly you want to specify a policy for.
If your needs are simple and so you don’t want to have different policies for iframe elements and scripts, then just use default-src to specify the same policy for both.
If your needs are more complicated and you want a policy for iframe elements that’s different than the policy for other resources, than use frame-src. Similarly, if you want a policy for scripts that’s different than the policy for other resources, then use script-src.
If you don’t want a policy for worker scripts different than the policy for other scripts, then you’re fine just providing a script-src policy, and can stop there.
If you do want a policy for worker scripts different than the policy for other scripts, then along with providing a script-src policy, provide a worker-src policy too. The worker-src one won’t effect browsers yet, but will future-proof things for when browsers do add support.
PS: is it even legal to "undeprecate" stuff?
Yes. Though I can’t remember ever seeing any other spec or working group do that, it was the right thing to do in this case—because the CSP spec authors and working group realized that child-src was a mistake, and frame-src was actually necessary and it was a mistake to deprecate it.
So they unwound those mistakes—and relatively quickly. And part of why it worked in this case is: frame-src wasn’t deprecated long enough for browsers to ever get around to dropping support for it, and also a lot of web developers never got around to using child-src to begin with.