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.
Related
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.
I am trying to understand how Content Security Policies can mitigate XSS-Attacks on Web-Servers. Suppose there is a XSS-vulnerability in an User-Input-Field. It can be used to induce Javascript, such as alert(1) but it can also induce much more serious input, such as a script to exfiltrate Cookies.
When i tried to implement a Content-Security-Policy on that Webserver, i have noticed that both
script-src 'self'
as well as
script-src 'unsafe-inline'
prevent the Cookie exfiltration, however 'self' also prevents alert(1) and unsafe-inline doesnt
I am not an expert to Web Engineering, so i do not know what inline or self even refers to. What do they refer to and what are the similarities and differences between the two and how does that relate to the results i got, when i tried to secure my webserver?
'self' is just a mnemonic (token) for self domain of website.
For example, the website is accessible as http://example.com, http://www.example.com, https://example.com, https://www.example.com. http://example.com:8080 etc.
Therefore you have to specify all these host-sources in the script-src directive, because you do not know via which URL user will access your website.
Alternatively you can just specify 'self', it will mean:
if user access webpage as http://www.example.com, browser will substitute this source instead of 'self'.
if user access webpage as http://example.com:81, browser will substitute this source instead of 'self'.
Note that it's better to have relative Urls in the HTML for 'self' token usage. If user acces webpage as http://www.example.com and in HTML code is using <script src='http://example.com/js/jquery.min.js'> - the script loading will be blocked.
In the connect-src directive the 'self' token additionally allows ws://example.com and wss://example.com in the CSP3-compatible browsers.
'self' is safe because it does not allow XSS via injection of inline scripts or third-party scripts.
'unsafe-inline' it's just a token which allows 3 kinds of inline scripts in the webpage.
'unsafe-inline' is unsafe because it allows XSS through script injection.
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 started exploring Content Security Policy on a website which uses inline scripts and other crimes. I configured CSP per header field like this:
content-security-policy: default-src *; frame-ancestors 'self'; style-src 'self' 'unsafe-inline' fonts.googleapis.com cdn.jsdelivr.net *.stripe.com; report-uri https://sentry.io/api/x/csp-report/?sentry_key=y
My problem now is that the browser complains with the following message:
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src *"
I read the documentation for default-src <source> which states that <source> can be one of the following sources:
<host-source>
<scheme-source>
'self'
'unsafe-inline'
etc.
It seems to me that the asterisk can only be used for host sources. But what else can I do since only one <source> seems to be allowed? default-src * 'unsafe-inline' would not be compliant, right?
My goal basically is to use a minimal CSP configuration which works (and can be embedded via iframe). I am aware that it's best practice to go on with specific rules.
It seems to me that the asterisk can only be used for host sources.
Yes
But what else can I do since only one <source> seems to be allowed?
Multiple <source>s are allowed.
default-src * 'unsafe-inline' would not be compliant, right?
It’s compliant.
You can use https://cspvalidator.org/ to check. Or https://csp-evaluator.withgoogle.com/.
But you really want to avoid specifying 'unsafe-inline' in any CSP policy. Using 'unsafe-inline' pretty much defeats the entire purpose of CSP.
What you want to do instead for any inline scripts causing CSP errors is: take the scripts out of your document and move them into separate files. That’s sort of the whole point.
But if you really must specify 'unsafe-inline', then as far as the dealing with the specific error cited in the question, you should only specify 'unsafe-inline' for script-src — because the error message says, “Refused to execute inline script.”
If you instead specify 'unsafe-inline' for default-src, then that causes the browser to fail to do CSP checks for any inline resources in your document — stylesheets, etc., too, not just scripts.
So if the only problem is an inline script and for some reason you can’t fix that by moving the script out to a separate file, or specifying a hash or nonce for it, then you should at least only specify 'unsafe-inline' for script-src.
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.