Related: Why is script-src-elem not using values from script-src as a fallback?
I am seeing a low of CSP reports where e.g. https://track.adform.net/serving/scripts/trackpoint/async/ is blocked due to the effective directive script-src-elem. As you can see in the policy below I am not defining script-src-elem but expect it to fall back to script-src or even default-src. That is my in my debugging this policy looks the way it does.
I have not been able to reproduce the report myself.
Full report:
{
"csp-report": {
"document-uri": "https://www.example.com/some/uri",
"effective-directive": "script-src-elem",
"original-policy": "default-src 'self' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;script-src 'self' 'unsafe-inline' 'unsafe-eval' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;style-src 'self' 'unsafe-inline' data: fonts.gstatic.com *.googleapis.com browser.sentry-cdn.com *.youtube.com i.ytimg.com sentry.io images.prismic.io *.atdmt.com *.adnxs.com *.google.se *.google.com *.facebook.com connect.facebook.net *.hotjar.com hotjar.io *.hotjar.io *.adform.net www.google-analytics.com www.gstatic.com www.googletagmanager.com stats.g.doubleclick.net;img-src 'self' * data:;report-uri https://example.report-uri.com/r/d/csp/reportOnly",
"blocked-uri": "https://track.adform.net/serving/scripts/trackpoint/async/"
}
}
I am only seeing it in the chrome browser on primarily Windows. There is a bug [1] report in the Chromium tracker but that was closed off without further investigation and seem to affect something else.
Is there something wrong with my policy or perhaps a bug should be opened in the tracker again?
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=880816
Script-src-elem being reported although script-src is defined
Chrome acts strongly with comply to CSP3 spec, it reports the violated-directive as effective-directive. Chrome sends effective-directive where violation should occurred if such directive will be presented in the policy.
Firefox despite CSP3 spec does send a really violated-directive as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.
The browser console always displays the actually violated directive as it present in the policy.
Therefore in case of policy:
default-src 'none'
Chrome sends a script-src-elem for <script> and <script src=>, and sends a script-src-attr for inline event handlers and javascript:-navigation, except one bug (this bug does not touch your CSP since inline scripts are allowed).
Forefox sends a default-src in the violation report.
Whose behaviour is more useful is an open question, but I prefer Firefoxes one. Because Chrome can make crazy anyone who looking for the cause of violations in the case of a long chain of fallback directives, such as in the case of the Worker, especially when some browsers skip some fallback directives in this chain.
So here we don't even need to "go to the doctor", in your case the script-src is really used for any scripts.
The right question is why https://track.adform.net/serving/scripts/trackpoint/async/ is occasionally blocked in the script-src directive despite the *.adform.net source is specified in it.
Since the situation cannot be reproduced, the only way is analyze the statistics - user agents and IPs.
If IP belongs to public hosting, you can just ignore such violations - it's a bots.
If is blocking the only one URL https://track.adform.net/serving/scripts/trackpoint/async/, it could be some browser "privacy" extensions like mentioned here, because this URL is a tracker.
Is the browser.sentry-cdn.com source mean you use a sentry? Does sentry shows the CSP errors? It should catch those, because CSP violations has built-in javascript errors handlers via SecurityPolicyViolationEvent.
PS: I have met only one odd "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36" which blocked all HTTPS: sources. As as it was seen from the original-policy, this user agent just removes all https:// from the policy.
Is there something wrong with my policy or perhaps a bug should be
opened in the tracker again?
I do not see anything wrong in your CSP. Anyway it should NOT lock https://track.adform.net/serving/scripts/trackpoint/async/.
IMHO to open a bug it need collect some specifics.
Related
I am working on Drupal 9.3.8 site and using CSP module to setup the CSP header.
There are few core dependencies or contrib modules which require unsafe-inline in CSP header but scanner recommends not the have unsafe-inline, so looking for the fix to remove the use of unsafe-inline.
Dependencies that require unsafe-inline:
Drupal core ckeditor, modernizer and AJAX calls - which can be handled by CSP module used above which adds unsafe-inline only when ckeditor renders, but not when only modernizer is required.
Google Analytics module - which adds the script inline instead of putting it in a file and include it on each page. We have the patch compatible with D7 but not for D8/9.
AntiClickJack snippet which is as below:
<style id="antiClickjack">body{display: none !important;}</style>
Solutions:
Installed and setup CSP module as mentioned above to handle Drupal core libs/dependencies requirement.
To handle only rendering of modernizer.js and unsafe-inline, will need customization to the CSP module.
For antiClickJack and google analytics script and style tags, cannot add hash or nonce as unsafe-inline will be ignored which will break the handling of Drupal core requirements
CSP header that I have is as below:
Content-Security-Policy: default-src 'self'; connect-src 'self' www.google-analytics.com; frame-src 'none'; img-src 'self' data: https://www.google-analytics.com; object-src 'none'; script-src 'self' www.googletagmanager.com www.google-analytics.com ajax.googleapis.com 'unsafe-inline'; script-src-elem 'self' www.googletagmanager.com www.google-analytics.com ajax.googleapis.com; style-src 'self' 'unsafe-inline'; frame-ancestors 'none';
Questions:
How to handle antiClickJack snippet to avoid the use of unsafe-inline?
Do we have a customized approach to add the google analytics script to a file instead of adding it inline?
Add the following hash to your style-src: 'sha256-NHgJfLahpnqTyd+gTNfZfM2wjTUfB3Wk1CvqZfZpeHY=' Most browsers will suggest a hash for you, or you can use https://report-uri.com/home/hash. Note that the hash works as long as the content is unchanged, so only use it for static code.
Google Analytics and Google Tag Manager are not easy to implement without 'unsafe-inline'. You might be able to move to a file, but I don't know if that has an impact on the order of events. You will also need to look into CSP nonces for the code they insert. You will need to configure them to use your nonce and make sure that a new nonce is created for every page load. My experience is that setting a custom value for the nonce and change it for every page load is not trivial or possible within some frameworks, but worth giving a try.
I am developing a website with Wordpress that includes a Gumroad script, in the console it throws the following error:
extended_bundle-2dd0f46384e8ed974d932b1190b99d42941abe18a7b69f4e8bd492fa0a309a13.js:1 Refused to connect to 'https://stats.g.doubleclick.net/j/collect?t=dc&aip=1&_r=3&v=1&_v=j87&tid=UA-29108090-1&cid=256380548.1611057176&jid=2069832337&gjid=1027868402&_gid=88988440.1611562559&_u=SCCAiEADRAAAAE~&z=875389156' because it violates the following Content Security Policy directive: "connect-src 'self' bam.nr-data.net www.dropbox.com s3.amazonaws.com/gumroad s3.amazonaws.com/gumroad/ www.google.com www.gstatic.com *.facebook.com *.facebook.net files.gumroad.com/ d1bdh6c3ceakz5.cloudfront.net/ *.braintreegateway.com www.paypalobjects.com *.paypal.com *.braintree-api.com iframe.ly gumroad.com".
I tried to fix it by putting the info in the meta, but I'm sure I'm wrong. what is the best solution to fix this? (I have never faced this problem before).
<meta http-equiv="Content-Security-Policy" content="default-src https 'self'; child-src * data: blob:; connect-src 'self' bam.nr-data.net www.dropbox.com s3.amazonaws.com/gumroad s3.amazonaws.com/gumroad/ www.google.com www.gstatic.com *.facebook.com *.facebook.net files.gumroad.com/ d1bdh6c3ceakz5.cloudfront.net/ *.braintreegateway.com www.paypalobjects.com *.paypal.com *.braintree-api.com iframe.ly gumroad.com; font-src * data: blob:; frame-src * data: blob:; img-src * data: blob:; media-src * data: blob:; object-src * data: blob:; script-src 'self' 'unsafe-eval' ajax.cloudflare.com static.cloudflareinsights.com js.stripe.com api.stripe.com *.braintreegateway.com *.braintree-api.com www.paypalobjects.com *.paypal.com www.google-analytics.com *.g.doubleclick.net optimize.google.com www.googleadservices.com www.google.com www.gstatic.com *.facebook.net *.facebook.com *.newrelic.com *.nr-data.net www.dropbox.com s.ytimg.com *.jwpcdn.com content.jwplatform.com/libraries/3vz4Z4wu.js *.jwpsrv.com blob: 'self' data: gumroad.us3.list-manage.com analytics.twitter.com 'sha256-VM/GRb7zfHAoT0vOuAlUed7we+jp8z0wsVKkGxFFsqI=' gumroad.com assets.gumroad.com; style-src 'self' 'unsafe-inline' s.ytimg.com ssl.p.jwpcdn.com optimize.google.com assets.gumroad.com; worker-src * data: blob:">
I tried to fix it by putting the info in the meta, but I'm sure I'm wrong.
To fix the issue you have to add https://stats.g.doubleclick.net host-source to connect-src directive.
It's 2 ways to publish CSP:
via meta tag <meta http-equiv="Content-Security-Policy" content="...">
via HTTP header "Content-Security-Policy: ..."
Avoid to use both ways at the same time - in case of 2 CSPs the rules will join with logical "AND" and you'll failed to get expected result.
Therefore you need to know in which way your Wordpress publish the CSP, and then to add the https://stats.g.doubleclick.net into meta OR into HTTP-header respectively.
Typically WP uses plugins to publish CSP. It can also be published in the .htaccess file.
Note 1: the console error you described could be not yours if you use iframe with third-party content (some external widgets, Google auth etc.). Because browser use one console to display CSP violations in any iframes.
Moreover, you could have installed some browsers plugins which tries to modify the viewed page. This can cause CSP violations too.
But lookes like it's caused by Google Adsense you place in web page. `https://stats.g.doubleclick.net. is used to collect stat of Google Ads.
Safari 10 throws a CSP-style-src-Violation in spite of calling a weg page with no style attributes inside.
The violation-message is:
Refused to apply a stylesheet because its hash, its nonce, or
'unsafe-inline' does not appear in the style-src directive of the
Content Security Policy.
Test web page is:
CSP test page
The only addon installed is Adblock-Plus. After removing the addon, the violation is not shown anymore. The rendered html source shows no style-attribute at all, with adblock or without.
Is there a way how to filter out these false violation messages?
They are misleading.
I have also faced the same issue.looks like if you mention the style directive its expecting style-src 'self' 'unsafe-inline'; hope it helps.
I cannot wrap my head around the CSP violation report below (sent by FireFox 44.0.2 / Ubuntu). What is really being blocked here and why?
It should be noted that it does not matter if I write 'self' or (as gets automatically translated in the report) https://www.example.com into the CSP header.
Also, I am not aware of anything missing from the rendered page.
So what can I do against it? (Apparently, I should not add reporting in my live site if every page triggers a fake violation report)
{
"csp-report":{
"blocked-uri":"self",
"document-uri":"https://www.example.com/foo/bar/baz.html",
"original-policy":"report-uri https://reportserver.example.com/ContentSecurityPolicy-report.php;
default-src https://www.example.com;
style-src https://example.com https://www.example.com https://fonts.googleapis.com;
script-src https://www.example.com https://code.jquery.com https://ajax.googleapis.com;
font-src https://fonts.gstatic.com",
"referrer":"https://www.example.com/foo/bar/wtf.html",
"source-file":"https://www.example.com/foo/bar/baz.html",
"violated-directive":"style-src https://example.com https://www.example.com https://fonts.googleapis.com"
}
}
By setting your policy to:
default-src 'self'; style-src example.com www.example.com 'self' https://fonts.googleapis.com 'unsafe-inline'; script-src 'self' https://code.jquery.com https://ajax.googleapis.com; font-src https://fonts.gstatic.com 'self';
I don't see any violations. I added the 'unsafe-inline' to style src, and 'self' to font-src.
I've seen this kind of CSP report (in September 2021) that doesn't make any sense with user agent
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
I'd assume that it's either an updated browser hitting some old bug or some browser extension that changes both the user agent and the browser behavior.
And yes, the server emitted Content-Security-Policy did include script-src 'self' 'report-sample' ... even though the reported violated-directive did not include either self nor report-sample. I haven't bothered to test with that old Firefox but I'd assume that it doesn't support 'report-sample' and it causes it to incorrectly parse the policy resulting in 'self' getting dropped, too.
If you see this same report from some more modern user agent, I'd be interested to know more details about your case.
This bug might also be related: https://bugzilla.mozilla.org/show_bug.cgi?id=1236222
We started using Content Security Policy (CSP) on our website and I noticed that many users violates CSP rules through webviewprogressproxy URLs. In such cases I receive the following report from CSP:
{"csp-report":{
"document-uri":"http://example.com/en/booking/b2",
"referrer":"http://example.com/en/booking/b1/nnn",
"violated-directive":"default-src 'self'",
"original-policy":"default-src 'self'; font-src data: 'self'; img-src 'self' www.google-analytics.com data: s3.amazonaws.com; script-src 'self' www.google-analytics.com; report-uri /cspreport",
"blocked-uri":"webviewprogressproxy://",
"source-file":"http://example.com/en/booking/b2",
"line-number":1
}}
User-Agent:
Mozilla/5.0 (iPhone; CPU iPhone OS 8_1_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12B440 [FBAN/MessengerForiOS;FBAV/28.1.0.50.260;FBBV/10708012;FBDV/iPhone7,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.1.2;FBSS/2; FBCR/giffgaff;FBID/phone;FBLC/en_US;FBOP/5]
As you can see, there is some URL with webviewprogressproxy protocol. However, we don't use this protocol and when we look at the User-Agent, it seems that some Facebook application on iOS causes this error, but I'm not sure about this.
Do anyone know what causes this kind of error and how we can avoid this?