In reality, we don't have a lot of truly secure facilities, but instead rely on legal process to stop bad actors, and make people whole after the fact.
On the web, there's always been a push for total security, which I don't think is useful nor particularly realistically implementable.
Nope, it's entirely possible to have the accompanied by a member of physical security the whole time. The question is always how valuable your security is vs the cost of maintaining it.
The idea behind CSP based on nonces (as opposed to the "old" approach of using whitelists) is that you add the valid nonce token only to the script directly sourced from your page, and trust propagates to other scripts loaded dynamically by the "loader" script. This way you no longer have to care about what domains the widget uses -- if you trust the initial script, give it a nonce and it will execute, along with the subresources it needs.
Of course you can still have a domain whitelist or use Subresource Integrity if you're loading scripts from potentially untrusted infrastructure. But the nonce-based approach is meant precisely to avoid the "moving target" problem you mentioned.
On the HN thread on the cited study, I posted [1] that C-S-P is 'another damn header' that has to be included to stay secure and, unlike many of the 'other damn headers', its value is hopefully fine-tuned to the particular protected resource, unlike a site-wide hardcoded string.
I think more so than another configuration helper tool, what the Web really needs is a CSP rule engine evaluator that allows rules to be specified declaratively ahead of time, and integrates with some existing web framework to allow the resulting C-S-P value to be spliced into the outgoing response. Portions of this approach are implicitly proposed by OWASP here [2], but I've yet to see it written down formally, as opposed to just some code example. Widely adopting this approach would result in a paradigm shift that lifts C-S-P from 'just a header' to a first-class construct integral to the operation of the web application.
[1] https://news.ycombinator.com/item?id=12408680
[2] https://www.owasp.org/index.php/Content_Security_Policy#Coun...
- Doesn't properly take into account default-src. We have default-src 'none', but it's telling us that we haven't set object-src to none.
- Says "Directive 'meta' is not a known CSP directive", despite the advice to use the meta tag here: http://www.html5rocks.com/en/tutorials/security/content-secu...
For reference these are the issues that came up with the CSP on the front end for our oembed:
https://oembed.fwdeveryone.com?threadId=Nh4apRjSR7qS5y4aGd3N...
Rolls off the tongue better than https://csp-evaluator.withgoogle.com.
In which case, quis checks ipsos checkers? ie will we eventually find we need a checker checker checker, and so on ad infinitum?
If you know of exploitable XSS vectors in SVG implementations, you should report them. Not only would you get some nice big bug bounties, you'd, you know, close XSS vulnerabilities for hundreds of millions of people.
