Reshaping web defenses with strict Content Security Policy
security.googleblog.com
Reshaping web defenses with strict Content Security Policy
1–10 of 25 posts
Re: Reshaping web defenses with strict Content Security Policy
#2CSP 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.
Re: Reshaping web defenses with strict Content Security Policy
#3This 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.
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...
Re: Reshaping web defenses with strict Content Security Policy
#4CSP 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…
> 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.
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.
Re: Reshaping web defenses with strict Content Security Policy
#5They really missed an opportunity to have their URL be https://evaluate-csp.withgoogle.com
Rolls off the tongue better than https://csp-evaluator.withgoogle.com.
Re: Reshaping web defenses with strict Content Security Policy
#6CSP 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…
SVG should only be executing in a null origin if it is not blocked by the CSP.
Re: Reshaping web defenses with strict Content Security Policy
#7CSP 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…
> 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. 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.
I have been tempted to go down the bug bounty route, but in this particular instance I might get a small win, but not contribute to the larger problem of browsers and javascript themselves. Browsers are a teeming big ball of complexity and rather than patch and forget, I would rather stick to a single duty, stripped down program like Lynx, or a hardened version of Firefox with heavy about:config tweaks. And of course, Javascript turned off at all costs. I routinely ask people on public forums to switch to Firefox and block JavaScript, and I am a firm advocate of Lynx for surfing text-based websites. I might not be able to view some websites, but that's on them. It's a webmaster's job to make a website accessible, not mine.
Re: Reshaping web defenses with strict Content Security Policy
#8Earlier quoted context omitted.
> 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. 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.
I have been tempted to go down the bug bounty route, but in this particular instance I might get a small win, but not contribute to the larger problem of browsers and javascript themselves. Browsers are a teeming big ball of complexity and rather than patch and forget, I would rather stick to a single duty, stripped down program like Lynx, or a hardened version of Firefox with heavy about:config tweaks. And of course…
That's all great and dandy for you and the few people inside your circle of influence but there's a bajillion people on the internet, using all kinds of devices, for whom this is impractical to impossible.
Even getting this kind of attack mitigated in one of the major browsers makes this a much less appealing thing to try and exploit and raises awareness of the problems potentially improving everyone's security.
Putting this kind of responsibility on others makes you part of the problem, instead you could help in being the solution. That's not to say webmaster shouldn't be doing a better job at this, but sometimes their abilities are limited. I'm surprised that anyone would be willing to then as a consequence let this be inflicted on others if they had the ability to do something substantial about it.
Re: Reshaping web defenses with strict Content Security Policy
#9Earlier quoted context omitted.
> 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. 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.
I have been tempted to go down the bug bounty route, but in this particular instance I might get a small win, but not contribute to the larger problem of browsers and javascript themselves. Browsers are a teeming big ball of complexity and rather than patch and forget, I would rather stick to a single duty, stripped down program like Lynx, or a hardened version of Firefox with heavy about:config tweaks. And of course…
Yeah, I'm going to go out on a limb and suggest that you haven't really looked into your ideas for these attacks, and if you did you'd discover they weren't actually exploitable.
Re: Reshaping web defenses with strict Content Security Policy
#10They really missed an opportunity to have their URL be https://evaluate-csp.withgoogle.com Rolls off the tongue better than https://csp-evaluator.withgoogle.com .
Agree with you, thought majority of the people will not pronounce this url ever.