On the Insecurity of Whitelists and the Future of Content Security Policy
research.google.com
research.google.com
- Header fatigue. For many people, CSP is 'yet another damn header' [1][2][3] we have to add to our websites. Although it's supposed to require careful thought and be tailored to the need of the particular resource being loaded, the typical programming model of the web separates payloads from headers, and therefore proper use of CSP needs a hook in your HTTP-server that calculates the correct header based off of a bunch of rules you set ahead of time and the URL (and maybe payload) of the resource. This integration typically isn't nicely present in HTTP-servers or web frameworks, so people hardcode headers and move on. (Maybe try a meta http-equiv instead??)
- The nonce approach proposed for CSP is essentially CSRF tokens all over again. I get why it works, but it's ridiculous that the server has to quasi-cryptographically pass tokens around inside the HTML that a third-party wouldn't have... the weakness of the protocol itself is showing; there has to be a better way to communicate cross-domain resource trust.
- Completely unrealistic thought experiment: block ALL cross-domain requests in a browser. Only allow <a> tags. Everything else has to be hosted on the same domain and proxied over. The incentives re-align; all the responsibility and blame will fall squarely on website operators to get their sites right.
[1] https://www.owasp.org/index.php/OWASP_Secure_Headers_Project...
But it is hard to put a good CSP policy on top of an existing website not designed with CSP in mind in the first place. That's were nonce can be a temporary measure to bridge the gap. I really see the nonce as a temporary workaround while migrating a site to CSP.
Really? I can't use a CDN for my images?
[a.] If cross-origin anything is forbidden by default, opt in to cross-domain images with CSP 'img-src'
[b.] No You Can't Use a CDN™, or rather, you can [1][2], but some portion of the domain name of the URL has to be the same, or you can only whitelist your own subdomains, or something of the like. This will have to trigger a larger conversation about the nature of subdomains, DNS, possibly TLS DV certs, and how you can prove that your own subdomains are not outside of your control -- both for the satisfaction of DV certs, but also to the satisfaction of CSP.
[1] https://azure.microsoft.com/en-us/documentation/articles/cdn... [2] https://www.maxcdn.com/one/tutorial/creating-cname-dns-recor...
Part of the problem is, right now, the 'default' CSP is neither opt-in, nor opt-out (EDIT: this is technically incorrect, but what I meant to say is, the effect of CSP defaults and their interplay with stuff like same-orgin policy isn't lockdown-by-default) It's whatever legacy behavior the browsers of the world have collectively implemented, but nonetheless pending each of their whims and changelogs. This makes it so that your CSP rules merely override the default, and you're not universally protected from just about anything when you don't specify a policy.
Not for everyone, but I can live with it.
You can use µMatrix[0] to browse like that and whitelist things as needed.
It's surprising how many sites break under same-origin-only rules. And by break I mean they don't even display any text despite the text being present in the markup.
(Also, I believe it's now called uMatrix; the greek letter is gone.)
Some 'strict-dynamic' deployment examples:
https://www.google.com/about/careers/jobs
https://www.google.com/maps/timeline
https://bugs.chromium.org/hosting/
[1] https://w3c.github.io/webappsec-csp/#strict-dynamic-usage
[2] http://www.slideshare.net/LukasWeichselbaum/making-csp-great...