Add unpkg to Content Security Policy (CSP) - html

How can I add specific libraries (ES modules) fetched through Unpkg to my Content Security Policy (CSP) policy - i.e. without allowing everything from Unpkg?
For example, this is how I add provide one library:
<script
type="module"
src="https://unpkg.com/web-social-share#latest/dist/websocialshare/websocialshare.esm.js"></script>
I tried various solution such as https://unpkg.com/web-social-share#latest/* or https://unpkg.com/web-social-share#* for my script-src policy but all resulted in an error:
Refused to load the script 'https://unpkg.com/web-social-share#latest/dist/websocialshare/websocialshare.esm.js' because it violates the following Content Security Policy directive: "script-src 'self' ...
Anything that seems to work is allowing everything from Unpkg which I would like to avoid.
<meta
http-equiv="Content-Security-Policy"
content="default-src 'self';
script-src 'self' https://unpkg.com/;" />

This is available only in CSP level 3: https://www.w3.org/TR/CSP3/#external-hash. But unfortunately you'll still need to support level 2. You can however use Subresource Integrity in most browsers.

Related

Unexpected blocked page when called from link in iframe to PDF file with chrome based browsers

I have a webpage in an iframe which contains a link to a foreign page with attributes target="_blank" rel="noopener". This link works well from the page itself and also from the iframe but only when called via context menu with the option open in new tab. A regular click opens a new tab and shows the correct URL but results in This page has been blocked by Opera ERR_BLOCKED_BY_CLIENT.
I looked around for help, disabled all addons to no avail and played the scenario in incognito mode as well, no change. The console on the error page shows VM589:1460 crbug/1173575, non-JS module files deprecated. This hint left me in the dark, however. I manipulated the attributes to target="_blank" rel="noopener" rel="noreferrer" or rel="noopener noreferrer" with no success. This all applies to Opera.
I tried Brave with the same result and error message, except Brave instead of Opera, of course. Edge joins the failure band. No surprise then to see This page has been blocked by Chrome proper as well.
This error applies to all PDF-file links from the iframe, normal external links work well. Firefox shows briefly PDF.js viewer in the new tab and then works normal. I had no chance to try links to YouTube or the like, but I guess there is ample evidence I hit a bug in the chrome PDF-rendering engine.
What to do? Who is interested in this bug and how to reach them? Or is there anything I can do in my code?
Browser use already longer time the Content Security Policy (CSP) to protect users from undesired content. The definition of undesired content can be made by the site owner. if the site owner hasn't done that, then some standard values are used, which are more restrictive.
The website https://content-security-policy.com/ explains it like this
What is Content-Security-Policy?
Content-Security-Policy is the name of a HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to restrict how resources such as JavaScript, CSS, or pretty much anything that the browser loads.
Although it is primarily used as a HTTP response header, you can also apply it via a meta tag.
The term Content Security Policy is often abbreviated as CSP.
What types of attacks does Content-Security-Policy help mitigate?
CSP was first designed to reduce the attack surface of Cross Site Scripting (XSS) attacks, later versions of the spec also protect against other forms of attack such as Click Jacking.
In your case you have to configure two hurdles for the user:
The iframe, required rule:
frame-src 'self'
The PDF, required rule:
object-src 'self' blob;
Essentially it's relatively safe to allow most things with 'self' but it's always good to disallow elements that are not used at all on the site.
Your Content Security Policy should look similar to this, and should allow PDFs in iframes:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self' blob:; style-src 'self'; frame-src 'self';
The best is to configure the CSP in the server configuration. This is not possible for every site owner though, and it's possible to configure the CSP in meta tags too. You could add this to your site inside the head-tag:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'self' blob:; style-src 'self'; frame-src 'self'">
Setting the CSP in the server configuration is the stronger approach though:
https://content-security-policy.com/examples/meta/
Here are more examples, including CSP related server configuration for Apache Web Server and Nginx Webserver:
https://content-security-policy.com/examples/
EDIT
If the PDF is hosted on another domain, then the CSP has to adjusted differently, more openly.
Different options for sources are explained here:
https://content-security-policy.com/#source_list
The iframe, required rule has to be adjusted.
It should be restricted either to a special domain with *.example.com or to a nonce with 'nonce-rAnd0m'.
The PDF, required rule has to be adjusted, the same advise like for point 1. is applying.
So even the PDF is external then, it doesn't mean that everything could be injected somehow in the website.
Assumed you use the option with the domain *.example.com it would look like or similar to this then:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src '*.example.com' blob:; style-src 'self'; frame-src '*.example.com'
Assumed you use the option with the nonce it would look like or similar to this then:
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'nonce-rAnd0m' blob:; style-src 'self'; frame-src 'nonce-rAnd0m'
I didn't test it, so slight adjustments might be required.

how to set multiple Content Security Policies in a chrome extension manifest.json file

in the Google chrome documentation I found that I can add content Security Policy to allow an external javascript file to work on my extension.
but I couldn't find how to add multiple ones. Is it an array of Strings?
"content_security_policy": "script-src 'self' https://example.com; object-src 'self'"
I tried to put multiple lines like that but it doesn't work. Goes error:
Refused to load the script https://example.com because it violates the following Content Security Policy directive: "script-src 'self' https://example.com". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
CSP policy is a single string (containing a semicolon-separated list of directives and their arguments). It applies to all extension pages.
If you need a single policy with multiple sources, you can do that. In fact, you already have that: 'self' and https://example.com are two sources.
Read about CSP in general and script-src directive, e.g. on the MDN.
Syntax
One or more sources can be allowed for the script-src policy:
Content-Security-Policy: script-src <source>;
Content-Security-Policy: script-src <source> <source>;
So you just need to space-separate them between script-src and the semicolon.
Make sure that your sources do not contain paths.
E.g. https://example.com is OK, but https://example.com/ or https://example.com/script.js are not.
If you need multiple independent policies for different pages, I'm afraid you can't do that.

Is this method of applying content security policy ok?

I am trying to add CSP to my web application, I have added the following meta tag in my index page:
<meta http-equiv="Content-Security-Policy" content="img-src 'self' data:;default-src *;style-src 'self' http://* 'unsafe-inline';script-src 'self' http://* 'unsafe-inline' 'unsafe-eval';" />
and Also the following my my web.config file on IIS:
<customHeaders>
<add name="Content-Security-Policy" value="default-src 'self' 'unsafe-inline' http://*.domain.com;
img-src 'self' http://*.domain.com data:" />
</customHeaders>
Is it necessary to add both meta tag and additional headers? or One of them is sufficient?
Does the meta tag policy override the custom header?
Does this script-src 'self' http://* 'unsafe-inline' 'unsafe-eval' mean that I can write inline JavaScript and use eval function inside my code? Does this rule override the policy set by headers? (because as far as I know in headers I have prohibited usage of inline JavaScript and eval function)
And my last question is if I use these settings, Should I use ng-csp or its other variant ng-csp="no-unsafe-eval" in my html?
Is it necessary to add both meta tag and additional headers? or One of them is sufficient?
One is sufficient. If you can make your server send the policy in a response header, that’s better. You don’t need to also specify anything in a meta element too, and there’s no advantage to it.
Does the meta tag policy override the custom header?
The meta policy will only override the header policy if the meta policy is stricter. See this answer:
What is happening when I have two CSP (Content Security Policies) policies - header & meta?
… which cites a part of the CSP that says, “adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource”.
Does this script-src 'self' http://* 'unsafe-inline' 'unsafe-eval' mean that I can write inline JavaScript and use eval function inside my code?
It would do that if your header also specified those values for script-src. But your header policy does not. So the browser uses the strictest policy, regardless of where it’s specified.
Does this rule override the policy set by headers? (because as far as I know in headers I have prohibited usage of inline JavaScript and eval function)
No, as the What is happening when I have two CSP (Content Security Policies) policies - header & meta? answer explains, you can’t override a strict policy by specifying a less-strict policy elsewhere.
So you’re best off specifying all your policy values in just one place, in a header (instead of meta).

Adding google fonts (fonts.googleapis.com) to CSP header

I am hosting a personal project on gitHub pages, and using cloudflare to enforce https. Now I would like to implement a CSP policy.
I tried adding meta tag to the head of my page:
<meta HTTP-EQUIV='Content-Security-Policy' CONTENT="default-src 'self' *.fonts.googleapis.com/* *.cloudflare.com/* *.fonts.googleapis.com/*;">
But I am getting the following error:
Refused to load the stylesheet
'https://fonts.googleapis.com/icon?family=Material+Icons' because it
violates the following Content Security Policy directive: "default-src
'self' .fonts.googleapis.com/ .cloudflare.com/
.fonts.googleapis.com/". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
This are the scripts that I am including:
<link href="https://fonts.googleapis.com/icon?family=Material+Icons"
rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Noto+Sans|Roboto" rel="stylesheet">
won't setting *.fonts.googleapis.com/* allow everything from the page?
Since this is the first time I am setting a CSP is this the correct way to set it for github pages? I have not found any reading on this yet.
Won't setting *.fonts.googleapis.com/* allow everything from the page?
Although this would be intuitive, the answer is no.
See the pretty good HTML5rocks introduction to Content Security Policy on the topic of wildcards (section Implementation details):
Wildcards are accepted, but only as a scheme, a port, or in the leftmost position of the hostname: *://*.example.com:* would match all subdomains of example.com (but not example.com itself), using any scheme, on any port.
So a working CSP for the two fonts could look something like this:
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https://fonts.googleapis.com/ https://fonts.gstatic.com/ 'unsafe-inline';">
Note 1: It's a good practice to use the corresponding CSP directives. In your case you should use the font-src and style-src like so:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; font-src 'self' https://fonts.gstatic.com/; style-src 'self' https://fonts.googleapis.com/ 'unsafe-inline';">
The advantage of using the corresponding directives is that your CSP gets pretty restrictive now. E.g., you're not allowing 'unsafe-inline' for script sources anymore. This means inline javascript is now forbidden. It's also forbidden to load scripts from https://fonts.gstatic.com/, which was allowed before. And so on...
Note 2: You can get rid of the 'unsafe-inline' keyword at all by using a hash or a nonce. I have not been able to make this work for this example but if you're interested, just take a look at the HTML5rocks intro again.

images from imgur.com is not displaying on website

I am using simple html tag to display images from imgur.com:
<img alt="Modern Dashboard Design" src="http://i.imgur.com/yst7lV9.png?1" style="height:550px; width:1024px" />
this was working few days back, but now it is not showing. Image is displaying on jsfiddle,but not displaying on this page:
http://www.ucom.my/p/admin-page-for-website-50
When you view the page source, you will find img tags.
What might be the reason?
Content Security Policy: The page’s settings blocked the loading of a resource at http://i.imgur.com/2qEeCDA.png (“default-src http://www.ucom.my”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://i.imgur.com/yst7lV9.png?1 (“default-src http://www.ucom.my”).
Content Security Policy: The page’s settings blocked the loading of a resource at http://i.imgur.com/GAXEkpu.jpg (“default-src http://www.ucom.my”).
Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src http://www.ucom.my”).
This can be seen when opening the Firebug console.
You have this in your head:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
This means you have deliberately blocked all requests to imgur or anywhere else. Change it to this:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src example.com;">
Or just remove it entirely.
A quick look in your console tells me you have a LOAD of security errors.
Refused to load the image 'http://i.imgur.com/GAXEkpu.jpg' because it
violates the following Content Security Policy directive: "default-src
'self'". Note that 'img-src' was not explicitly set, so 'default-src'
is used as a fallback.
And this happens because:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
this line of code exists which disallows content from foreign sources.
Open your browser's developer tools. Look at the console. Read the error messages.
Refused to load the image 'http://i.imgur.com/GAXEkpu.jpg' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
You've included:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
in your page, which bans the use of <img> elements with a src on a different domain.
Have a look to your browser inspector...
It says:
[Error] Refused to load http://i.imgur.com/2qEeCDA.png because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.
[Error] Refused to apply a stylesheet because its hash, its nonce, or 'unsafe-inline' appears in neither the style-src directive nor the default-src directive of the Content Security Policy. (admin-page-for-website-50, line 87)
[Error] Refused to load http://i.imgur.com/yst7lV9.png?1 because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.
[Error] Refused to apply a stylesheet because its hash, its nonce, or 'unsafe-inline' appears in neither the style-src directive nor the default-src directive of the Content Security Policy. (admin-page-for-website-50, line 89)
[Error] Refused to load http://i.imgur.com/GAXEkpu.jpg because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.