10

I'm trying to develop a CSP for the site https://www.lidl-tour.ro.

Right now there is a policy than runs in report-only-mode, so nothing is blocked at the moment.

The site contacts googleads.g.doubleclick.net and stats.g.doubleclick.net. So I have put these hosts on the whitelist.

But it seems that these sites then (make the user) load content from www.google.com and www.google.YOURTLD. I can see CSP violations being reported where the browser wanted to contact https://www.google.com.cy, https://www.google.co.uk, https://www.google.it, https://www.google.de and so on.

Now I don't want to put all google domains into the CSP.

I thought about allowing https://www.google.* (I don't know if this is even valid in a CSP) but this expression wouldn't match URLs like https://www.google.co.uk.

So, how can I build a valid CSP in this case?

  • 2
    Have you had a look at [this][1] answer? Looks like your question is quite similar. [1]: stackoverflow.com/questions/34361383/… – Wietze Jan 27 '17 at 10:02
  • Thank you for the comment. The problem is very similar, indeed. – HorstKevin Jan 27 '17 at 13:39
  • The problem is not your CSP, it is how promiscuous those cross-site-requests have become. I installed a request policy addon to my browser last week, and the amount of different domains being pulled by a single page is baffling. – Mindwin Jan 27 '17 at 14:28
  • i've not tried this, but perhaps you could use the HTML endpoint and some JS to dynamically set your policy after sniffing the TLD: <meta http-equiv="Content-Security-Policy" content="..."> – dandavis Feb 1 '17 at 20:18
4

As an addition - not only is it not supported, you wouldn't want it even if it was supported.

Because https://www.google.* would then match not only https://www.google.co.uk but also https://www.google.evilattacker.com. And you can be sure that is exactly the URL attackers would use, as it would give them best leverage against CSP on majority of sites.

  • Good point you have here. – bbaassssiiee May 26 '18 at 13:28
3

I hope that Google reads this too, they should change GoogleAds and Google Analytics by serving these images from ar.images.google.com and be.images.google.com, then we can set up our CSP using image-src: 'self' *.images.google.com. This is because using the current CSP standard we cannot use a wildcard for the top-level domain in the Content-Security-Policy header, only on the hostname. And for Google analytics it looks like a change without a lot of impact.

Btw: Sentry.com offers a CSP reporting url.

2

The problem here isn't with your CSP, but more to do with how the aims of CSP and Google Analytics and similar tracking systems are at odds with one another.

The Content-Security-Policy header was designed under the assumption that site owners know and control all content that is executed on their pages, and that it's therefore possible to exclude everything else. This isn't really the case with tracking and advert code on pages, where a third party is running their code too.

For "high security" applications, such as internet banking websites, payment processors, and similar, it's often possible to minimise the number of third party systems used - banks will tend to run their own analytics systems, rather than using Google's, and won't have third party adverts on pages within the internet banking application. That points to one option to have a valid CSP: host your own tracking and advertising code on a domain you control. This isn't always viable for a smaller business.

You could also look to move secure elements of your site to a subdomain, and apply a strict CSP to that, with a more relaxed policy on the open parts. This would mean that static content, or content which you are confident can't be modified or added to by users, could be served with adverts/tracking, while authenticated sections, or sections where user content is displayed, could be restricted to known domains. It's not perfect, but it's better than an open CSP allowing all hostnames.

0

Have you considered using an online tool e.g. report-uri?

[updated]

Host wildcards aren't legal (see this spec):

Each source expression's host name MAY contain up to one wildcard (*) and it MUST be the left-most DNS label.

Have you considered serving your web pages with a different CSP header depending on the users' geolocation? So people from the UK would get a CSP that allows *.google.co.uk, and so on.

  • Yes, I have. There I see the violations against my current policy. I'm not sure that I understand your point. – HorstKevin Jan 27 '17 at 12:57
  • 1
    @HorstKevin I wasn't trying to make any particular point, but looked like you were trying to write your own policy by hand. Regarding your problem, wildcards on the left-hand side of a domain are the only one allowed. See wiki.mozilla.org/Security/CSP/Specification#Hostname_Wildcards "Each source expression's host name MAY contain up to one wildcard (*) and it MUST be the left-most DNS label." – lorenzog Jan 27 '17 at 13:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.