Content Security Policy multiple nonce - javascript

I have a single page application (built in .net core MVC 2.2), where html section are loaded on the fly.
On main document, added CSP policy with a dynamically generated header looks like:
Content-Security-Policy: script-src 'self' 'nonce-I64vb811BxRNGV9Xf0pM'
Then comes a page section loaded via jquery ajax load function. page section contains a script (from src) with a nonce. Page section served with CSP header looks like
Content-Security-Policy: script-src 'self' 'nonce-ci5TQsyidT8x2jwBLRHS'
all good but browsers (chrome, safari blocking the script), with message:
jqueryscriptsbundle.js:formatted:43 Refused to execute inline script
because it violates the following
Content Security Policy directive: "script-src 'self' 'nonce-I64vb811BxRNGV9Xf0pM'
So browser is comparing nonce of script i.e. ci5TQsyidT8x2jwBLRHS with root/main page nonce value I64vb811BxRNGV9Xf0pM hence script blocked.
Is it correct behavior ? What can I do to make it work?

Your initial CSP, loaded with the page, provides a nonce. What you're trying to do is add another nonce, via Ajax, after the initial page load. CSP explicitly doesn't allow this; that's not a bug -- it's the entire point.
What you might do is allow a script-src of strict-dynamic. This allows you to authorize a script, and anything loaded by that script is also authorized. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

Related

Electron.js does not load jQuery due to security policy

I am trying to load jQuery in Electron (v. 16.0.0), but I get this error:
Inside the head element I have included this line:
<meta http-equiv="Content-Security-Policy" content="script-src 'self';">
Also, inside the body element, I am trying to load jQuery like this:
<script src="https://code.jquery.com/jquery-3.6.0.min.js" integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4=" crossorigin="anonymous"></script>
I have tried so many ways to find a solution for this, but to no avail. Previously, I also tried to load jQuery like this, but it gave me a similar error, shown below:
<script>window.$ = window.jQuery = require('./libraries/jQuery/jquery.min.js');</script>
Answers to a related question did not work for me either. What should I do?
The reason Electron, or any other Web browser that implements Content Security Policy, for that matter, would correctly refuse to load a script from an arbitrary origin (URL), or even an "inline" script (e.g. script text inside a script element), is because your security policy is explicitly specified to deny such attempts, with that meta element you said you added:
<meta http-equiv="Content-Security-Policy" content="script-src 'self';">
Why did you add it? Was it there by someone else's hand? Why is it there? It's the reason why Electron denies loading of the scripts in question.
The value of the content attribute above has the effect of instructing Electron to only allow loading scripts from the same origin as the origin of the document containing the meta element. That effectively excludes every other origin like https://code.jquery.com and inline scripts (which have to be allowed explicitly in this case because self denies these). Basically, the value is to be interpreted as "only allow loading scripts from the same site". Inline scripts are not considered as "same site".
Simpler put, you yourself prohibit loading of scripts from the kind of locations you then attempt to use, with that meta element.
You need to learn how Content Security Policy mechanism works and applies in your case. You will have to decide whether you want to allow loading of scripts from domains like code.jquery.com, or whether, for example, you will only want to allow loading scripts from your website, which in turn will probably necessitate you copying the JQuery library you want to use to be served by your website. You also will have to decide if you want to allow "inline" scripts on your site, for whatever reason you may consider necessary.
The security policy mechanism itself is very useful, don't shy away from it, it's there for a reason -- to help you prevent abuse of your site users by malicious scripts loaded by other malicious scripts or mechanisms. But you need to use it correctly, obviously.
You have 2 issues because of jQuery:
script-src 'self' does not allow to load script from https://code.jquery.com/jquery-3.6.0.min.js, that's why you observe Refused to load the script 'https://code.jquery.com/jquery-3.6.0.min.js'... error.
You have to adjust your CSP at least as script-src 'self' https://code.jquery.com;.
After page loads, the jQuery pick up all scripts having $() and place them into one inline script in the <head> section. That's why you observe Refused to execute inline script ... error.
This inline script can be resolved with either 'unsafe-inline' or 'unsafe-eval' or 'nonce-value'(for jQuery > 3.4).
Allowing 'unsafe-inline' is a very harmful advice, since such CSP will not protect against XSS at all (https://youtu.be/zlH_bBQMgkc?t=717).
Also Electron does not have the technical ability to refresh the 'nonce' value.
Therefore, the most secure CSP you can do is:
script-src 'self' 'unsafe-eval' https://code.jquery.com;
or much better:
default-src 'self'; script-src 'self' 'unsafe-eval' https://code.jquery.com;
Note: Contrary to a common misconception, 'self' does not mean the Same Origin Policy, CSP interprets 'self' much more broadly.

Electron Confusion about Security

Ok, im just lost. I opened an electron start app and added one simple code, to console log on button press. The function is in a file renderer.js and in being called in in my index.html. Why when I press the button
I get this message ....
Refused to execute inline event handler because it violates the following Content
Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a
hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution.
Why would I not be allowed to execute something inline? An external source seems more vulnerable. Can anyone clear this up for me please?
Content Security Policy is using to avoid XSS based attacks in browser.In electron the background is running in a chrome engine, so the code is actullay running in a chromium browser.This browser is prone to all security issues that a browser is having
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.
you can add the following code at the top of HTML to avoid the content security issue. this new header will allow the inline code to execute
<meta http-equiv="Content-Security-Policy" content="script-src 'self';">
What this meta tag will do ?
Allows
With the above CSP policy, the following are allowed to load and execute in the browser:
<!-- allowed by 'self' -->
<script src="/js/some-file.js"></script>
<!-- allowed by https://js.example.com -->
<script src="https://js.example.com/file.js"></script>
Blocks
The Example Policy above will block the following from loading or executing in the browser:
<script src="https://attacker.example.com/file.js"></script>

It is possible to override/remove page Content Security Policy through the external script?

I'm write an external script for a single web page and i need to make one POST JSON request to another resource through this script.
However, when i do, it throws CSP error: "Refused to connect to <URL> because it violates the following Content Security Policy directive: "connect-src 'self'".
I looked into the web page and see meta tag which contain a Content-Security-Policy with CSP content. However, i tried manually add my <URL> to CSP connect-src content, but it is still not working.
Questions:
can i change CSP through the external script? How?
maybe any workaround for this?
The error message is saying the setting that needs to be changed:
it violates the following Content Security Policy directive: "connect-src 'self'"
So you need to set the 'connect-src' directive to something other than 'self', which might have been set by default.
You said you tried to add the URL that you're trying to connect to. That is not quite right - you need to add just the host part, rather than any of the path.
So the connect-src part of the CSP header should look like:
connect-src 'self' https://*.example.com
If you update your question with what you tried, if it still isn't working, the exact error could be diagnosed.

Refused to load the font '<URL>' because it violates the following Content Security Policy directive default-src ,so default-src is used as a fallback

I am creating a web app using the mean stack in angular 6 but I am getting below error message on the browser console.
"Refused to load the font '<URL>' because it violates the following
Content Security Policy directive: "default-src 'self'". Note that
'font-src' was not explicitly set, so 'default-src' is used as a
fallback."
Code:
getUsers() {
return this._http.get("/api/users")
.pipe(map(result => this.result = result.json().data));
}
Content security policy is a way for modern browsers, to define a set of restrictions when loading remote resources.
Response headers from the HTTP protocol can set those policies:
Content-Security-Policy header (official), X-Content-Security-Policy (supported by Mozilla Firefox and IE10) and X-WebKit-CSP (supported by Google Chrome and Safari) HTTP response headers with the list of Content Security Policy directives. (from seckit drupal module)
You can set different policies to different types of elements in the DOM (e.g <img>, <script>, <object>, <embed>, <iframe> and so on...), to restrict requests that originates from that element.
So you need to change 'self' to one of the following:
'none' - block content from any source
'self' - allow content only from your domain
'unsafe-inline' - allow specific inline content (note, that it is supported by a subset of directives)
'unsafe-eval' - allow a set of string-to-code API which is restricted by default (supported by script-src directive)
Wildcards (*) are allowed:
* - load content from any source
*.example.com - load content from example.com and all its subdomains
example.com:* - load content from example.com via any port. -
Otherwise, it will use your website default port
Adding 'self' and data: to the font-src works for me.
Content-Security-Policy: font-src 'self' data:;
font-src reference doc from MDN
The Content-Security-Policy header is set by your api. Check your api response for its value.
As per the error, I think your fonts are loaded from a different domain than your application domain. Unless your api whitelists that domain, your browser will not load the font.
Example:
Content-Security-Policy: font-src https://example.com/
just close all browser, clear cache and restart VSC or your code editor. Ir worked fro me.

Why isn't this inline javascript blocked by content security policy?

I have a page that I set the script-src of the content security policy like this:
script-src 'self' *.uservoice.com *.intuit.com ajax.googleapis.com localhost:*
When I load the page with a hard-coded inline script I have created myself to test, it is blocked like expected:
Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src 'self'
*.uservoice.com *.intuit.com ajax.googleapis.com localhost:* ". Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce
('nonce-...') is required to enable inline execution.
However, when I insert a new script tag dynamically, the script isn't blocked, for example, this still executes:
$("body").append("<script>alert('xss');</script>")
I am using Chrome as the browser here for testing. I was hoping that this script would be blocked as well, since that would really help to prevent xss. Is there something I can change to block this type of script injection as well?
The script you add with append or innerHtml won't be executed unless you use eval(). So it's not violating CSP.
Although this may look like a cross-site scripting attack, the result is harmless. HTML5 specifies that a tag inserted via innerHTML should not execute. 1
See script elements inserted using innerHTML do not execute when they are inserted.

Categories