Why files ICO and PNG are being blocked by CSP? - content-security-policy

We got an error:
.ico' because it violates the document's Content Security Policy.
.png' because it violates the document's Content Security Policy.
but img-src is defined as: img-src * data:;
I assume that ico and png are not defined as images? what definition is missed?

Related

javascript click function causes Content Security Policy error

One of my chrome extension content scripts is executing a click function on an element like this
var currencySelectorLink = document.getElementById('switcher-info');
currencySelectorLink.click();
However the last line is causing the following error:
Refused to run the JavaScript URL 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. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
I've spend multiple hours now trying to figure this out, maybe some of you will have an idea how to fix it. I absolutely have to trigger this click event, there is no way around it
EDIT:
After some more investigation I found out that it happens, because the link has href attribute with inline javascript:
<a class="switcher-info notranslate" href="javascript:void(0)" id="switcher-info"></a>
anybody has any ideas how to bypass that? If I do this:
currencySelectorLink.href= '#' ;
then error is gone, but it breaks website functionality and not exactly expected behavior comes out of this click event
All that the <a href="javascript:void(0)" code does is to prevent following on the link. You can do the same more pretty way:
currencySelectorLink.href= '#' ;
currencySelectorLink.addEventListener("click", function(event) {
event.preventDefault(); // Prevent default action (a following a link)
}, false);
Note. Since you call click() you already have some event handler. You can insert event.preventDefault(); into it instead of add a second handler. And use:
<a class="switcher-info notranslate" href="#" id="switcher-info"></a>
without javascript:void(0).

Getting content security policy error while hash is included

I have a problem although i have included (as you can see) the hash for inline style="height:18px" (attribute) i still get csp error (pages are in ghostjs )
Refused to apply inline style because it violates the following Content
Security Policy directive: "style-src 'self' maxcdn.bootstrapcdn.com
fonts.googleapis.com https://intercom.help/_assets
'sha256-HKIQe1rxf7BKTQyeVymEQz4wG30GqXPn7nokufiyhRk='".
Either the 'unsafe-inline' keyword, a hash
('sha256-HKIQe1rxf7BKTQyeVymEQz4wG30GqXPn7nokufiyhRk='), or a nonce ('nonce-...') is
required to enable inline execution.
Content Security Policy whitelist hashes doesn't work for inline style attributes but only for inline styles. Maybe in CSP 3.0 will add this functionality
Works for
<style>
body { colod: red; }
</style>
But DOES NOT work for
<body style="color:red;">
</body>

How can one implement Google-signin and CSP rejection of inline stylesheets?

I'm trying to enable the Content-Security-Policy header on my website. I have the following header set:
Content-Security-Policy:default-src 'self'; script-src 'self' https://apis.google.com/; font-src 'self' https://fonts.gstatic.com/; style-src 'self' https://fonts.googleapis.com/ 'sha256-W/8NeLkjrtPkUUfkFDNutwiyHLsvDJAxC+dO5tQP/90='; child-src 'self' https://accounts.google.com/
This works great in Firefox. That hash in the style-src section matches the inline styles that Google-signin uses. The problem is, per Chromium Bug 546106, the hash is ignored because it's on a style, rather then a script. Worse still, from the comments Chrome/Chromium developers believe this is correct behavior, and is intended (that said, they haven't set it to "WONTFIX" yet).
I really don't want to enable 'unsafe-inline' if I don't have to.
Is there a way with Google-Signin to tell it not to use inline styling? Is there another way?

clikjacking Implementation issue

I have added the following meta tag to avoid clickjacking in my website.
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
But it throws "Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-CwE3Bg0VYQOIdNAkbB/Btdkhul49qZuwgNCMPgNY5zw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback."
Add
style-src 'unsafe-inline' 'self'
Or move the inline CSS to an external file. However, it's incredibly common to allow inline styles even though there is some risk involved.

Stop IE8 from opening or downloading a text/plain MIME type

I'm dynamically generating a text file in PHP, so it has a .php extension but a text/plain MIME type. All browsers display the file as nicely preformatted text, except IE8.
Googling tells me that they've added security where if the HTTP header content type doesn't match the expected content type (I think based on the extension and some sniffing) then it forces the file to be downloaded. In my case I have to open it, and also give it permission to open the file I just told it open! That's probably a Win7 annoyance though. Serving a static plain text file works fine, of course.
So can I stop IE8 from downloading the file and get it to view it normally? The code has to run on multiple shared hosting environments, so I think I'm stuck with the .php extension.
Add this to your HTTP header:
X-Content-Type-Options: nosniff
It's an IE8 feature to opt-out of its MIME-sniffing.
Source
Alternatively, you can "trick" IE8 into thinking that it is indeed serving up a text file. These 2 lines do it for me and don't involve using non-standardized "X-" headers:
Header("Content-Type: text/plain");
Header("Content-Disposition: inline; filename=\"whatever.txt\"");

Resources