If browsers were serious about cross-site content issues, Google Ads wouldn't work. Google insists in their policies that their ads must not be placed in IFRAME blocks,[1] where they can't see the page context. Yet, for security, you want any outside content that executes code sandboxed in an IFRAME.<p>[1] <a href="https://support.google.com/adsense/answer/3394713?hl=en" rel="nofollow">https://support.google.com/adsense/answer/3394713?hl=en</a>
This tool they just released, is hopefully helpful, and will help site administrators craft specific CSPs for specific parts of their site -- other, more generic tools already exist.<p>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.<p>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.<p>[1] <a href="https://news.ycombinator.com/item?id=12408680" rel="nofollow">https://news.ycombinator.com/item?id=12408680</a><p>[2] <a href="https://www.owasp.org/index.php/Content_Security_Policy#Countermeasure" rel="nofollow">https://www.owasp.org/index.php/Content_Security_Policy#Coun...</a>
Fantastic tool, though it seems to have a couple possible issues:<p>- 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.<p>- Says "Directive 'meta' is not a known CSP directive", despite the advice to use the meta tag here: <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/" rel="nofollow">http://www.html5rocks.com/en/tutorials/security/content-secu...</a><p>For reference these are the issues that came up with the CSP on the front end for our oembed:<p><a href="https://oembed.fwdeveryone.com?threadId=Nh4apRjSR7qS5y4aGd3NMA" rel="nofollow">https://oembed.fwdeveryone.com?threadId=Nh4apRjSR7qS5y4aGd3N...</a>
They really missed an opportunity to have their URL be <a href="https://evaluate-csp.withgoogle.com" rel="nofollow">https://evaluate-csp.withgoogle.com</a><p>Rolls off the tongue better than <a href="https://csp-evaluator.withgoogle.com" rel="nofollow">https://csp-evaluator.withgoogle.com</a>.
This stuff is not my area of expertise but am I correct in assuming we're talking about a "checker checker"?<p>In which case, quis checks ipsos checkers? ie will we eventually find we need a checker checker checker, and so on ad infinitum?
CSP is another baseline config that web application developers consistently don't include for whatever reason. It could be plain ignorance, but I think it goes deeper than that: I think CSP is too specific for the larger problem at hand which is Javascript itself. If I want to perform XSS on a site, I will find a way. There are still unpatched SVG vectors I can use in Chrome which have gone un-noticed for the longest time, and they will, can, and are being used today. There's just too many code paths in browsers to exploit, and CSP only partially addresses the problem. I'm still seeing TrueType libraries from the 90s executing arbitrary code in browsers, and it's 2016.