Sometimes I observe CSP violations for frame-src in the collected reports which have an empty blocked-uri attribute. The user agent indicates that the violations was triggered within Chrome 75 on Windows 10.
The policy mainly looks like default-src 'self' 'unsafe-eval' ; frame-src https:
I didn't succeed in reproducing this type of violation, nor is there any complaint about a blocked/missing feature.
Any idea what could be the reason for these violations?
After playing around a bit: Such violations are triggered when the framed page internally navigates to a domain which is not allowed by the parent's policy. For security reasons it's OK to leave the blocked-URI field empty in this case as otherwise the target domain would be disclosed to the owner of the framing page.
Related
If the user has no activity(mouse, keyboard) in some period of time, API'S not working, I inspected and went to the network tab and found CSP is blocking.
Attempt:
<meta http-equiv="Content-Security-Policy"
content="default-src 'self';script-src 'unsafe-hashes' 'unsafe-inline' 'my-urls' ;">
Tried by adding meta link, but it's not working.
Since you observe CSP blocking, you already have a CSP published in the page. You can't relax this CSP by publishing a second CSP in meta tag, you need to edit a first one.
You can check what CSP your already have in browser, a tutorial is here.
XHR requests are covered by connect-src directive, therefore you have to add connect-src 'self' or connect-src https://your_domain.com if you perform connect to a site's own domain.
But first check a "Console tab" - it should be a CSP violation message like:
Refused to connect to wss://example.com/ because it violates the following Content Security Policy directive ...
Refused to connect to https://example.com/ because it violates the following Content Security Policy directive ...
You need to verify that wss://example.com/ or https://example.com/ is your legitimate domain, because this can be antics of some browser plugin or third-party iframe on page.
After thar you can add wss://example.com/ or https://example.com/ (depending what is blocked) into connect-src directive.
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 add CSP to our web site, using report-only (to report-uri.com).
It seems to work as expected for most cases, but google related sites gets reported even if the URL is added to the header.
Here´s the relevant part of header as it appears in developer tools:
connect-src 'self' https://stats.g.doubleclick.net
I am still getting this violation:
"blocked-uri": "https://stats.g.doubleclick.net/j/collect"
I have experienced similar issues with other Google related sites as well.
The problem is that we're using Google tags and analysis, so I cannot block the sites out.
This particular problem seems to come from Chrome only.
In addition to blocked-uri, note in the reports on the original-policy field - is there your CSP with the connect-src 'self' https://stats.g.doubleclick.net rule or not.
Looks like some ISPs, in violation of RFCs, cache site responses along with HTTP headers. At least after the changes in the CSP, within 2 weeks there is violation reports having the old CSP in the original-policy field.
And it feels like you changed the rules in connect-src directive recently.
List of sources connect-src 'self' https://stats.g.doubleclick.net is not complete for Google Analytics, you can insert own Google Analytics ID and check. Here is comprehensive test of Content Security Policy for GTM.
Here is initial CSP for GA + GTM. The initial because though GTM you can embed a lot of third-party scripts from vary sources.
When implementing csp-header, I have specified my policy as:
default-src 'self'; script-src www.gstatic.com; Since I have not declared script-src-elem directive in my csp policy, as stated in this mdn documentation, I was expecting policy defined for script-src to be used for script-src-elem directive as well. However, I see violation being reported as "violated-directive":"script-src-elem" "blocked-uri":"https://www.gstatic.com/blah/blah".
Any idea why this behavior is happening?
After seeing this exact same pattern in some of my applications, I finally got to the root of this!
The weirdness we were seeing was that CSP reports were coming in for a hostname which was definitely in the script-src directive; and we know that script-src-elem is supposed to fall back to those directives. From that perspective, it should have been literally impossible for these reports to happen.
Here's what we found: the users these reports were coming from were using the PrivacyBadger browser extension, which was leading to false positive CSP reports for the hosts (Google) that it blocked. I didn't dig too far into it, but here's my theory on how that happens:
The Content Security Policy performs a pre-request check for the JavaScript include on the page (eg. gstatic.com or google-analytics.com). The pre-request check passes, because the hostname is allowed in the policy.
The browser initiates a request for the resource
PrivacyBadger intercepts the request via the browser's onBeforeRequest API (see PrivacyBadger source and Chrome documentation)
ProvacyBadger returns a surrogate data blob for the asset. It does this to ensure that code which relies on the real javascript (eg. window.ga) won't break.
The browser then performs a post-request check against the returned base64 blob
The post-request check fails - because the policy does not allow data: for script-src
The browser sends a CSP report for the blocked asset.
This seems like it might be a browser bug - because the report reflects the original asset's third party hostname; while the blocked content is actually a data: blob that was returned via the intercepted request.
From the documentation you linked to: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src-elem
The HTTP Content-Security-Policy (CSP) script-src-elem directive specifies valid sources for JavaScript elements, but not inline script event handlers like onclick.
Without seeing the rest of your code it is a safe assumption that you are seeing this error as a result of an inline event handler and will need to define script-src-elem in your CSP policy.
script-src-elem definitely does fallback to script-src in browsers on the Chromium engine. Check the Chrome console, the warn will looks like:
... Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
Gecko-browsers does not support script-src-elem and use script-src directly.
The CSP2-browsers in violation reports sends a violatied directive resulting after all fallback chain. But CSP3-browsers send a "theoretically" violated directive and than perform fallback if directive was omitted. This introduces some confusion.
script-src-elem have nothing to do with inline event handler like onClick() -this is noted in MDN docs. script-src-elem controls only <script>...</script> and <script src='...'> elements (and javascript-navigation).
"blocked-uri":"https://www.gstatic.com/blah/blah" says that https://www.gstatic.com host-source was blocked, not inline event handler.
Inline event handlers do lock in the script-src-attr directive and report will looks like "blocked-uri":"inline".
Looks like you edit a copy CSP, but server issues another as default. Please look the "original-policy" filed in the report's JSON. Is it contains you real CSP or some default one?
PS: To detail analyse what's going on it need to look a full violation report and a your full CSP (print screen of browser console messages will be very helpful). Because script-src www.gstatic.com; is totally enough for CSP3-browsers to allow any resources from 'https://www.gstatic.com'. (CSP2-browsers requires more rules but you shown violation report sent by CSP3-browser).
I know I'm late to this, but this thread brought me to the solution for my case:
Disable the NoScript-Addon in Chrome.
I have currently an issue with a SharePoint web application, where all websites return a response header content-security-policy: default-src 'self'; object-src 'none'; form-action 'self', which breaks the website's view using Chrome or Firefox, as styles won't be applied and Javascript won't be executed.
Console-Log
Refused to execute inline script because it violates the following Content Security Policy directive: default-src 'self'.
Either the 'unsafe-inline' keyword, a hash ('sha256-WFRyoBrQbrYtLpGIdyBszDzxQni3b0V/wUirab0OhKM='), or a nonce ('nonce-...') is required to enable inline execution.
Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
The problems only occurs if the websites are addressed using HTTPS. I already checked the HTTP Response Headers in IIS. content-security-policy is not specified. If I add it myself, it gets overwritten and is not sent in the response header. There are only two solutions installed, which do not mess with the response headers.
Has anyone an idea what else could change the custom response header and overwrite the one defined in the web.config? Or is there an other way to change the Content-Security-Policy?
I tested changing the IIS Response Headers by configuring the "CustomHeaders"-section in the web.config, by writing custom IIS modules, which modified the headers using the request lifecycle, and also by writing additional rules with the URL Rewriting tool. Nothing worked...
In the end we found out someone extended the firewall, which onwards would add new header and overwrite my changes of the HTTPS response. Mystery solved :)
In my case, I was asked by Network and Information Security Team to add the Content-Security-Policy: default-src 'self'; header in my IIS 8.5 SharePoint Server 2016 Publishing website which affects all the system pages and the browser refuses to execute the scripts and in console we got this error
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-HU8dCwZsqh4m8QG0y6qanyzPx1d6YSGHuAN0QXmxZvw='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
I then change the header to Content-Security-Policy:frame-ancestors 'self'; and it resolves the issue.
I actually got this from the JohnC's Answer that helps me resolving the issue