Oh, not CSP as in concurrency. Makes more sense now.
I assumed Constraint Satisfaction Problem
I had the same thought. It would be good to adjust the headline accordingly.
Neatly Bypassing Content Security Policy
21–30 of 38 posts
Re: Neatly Bypassing Content Security Policy
#22Just adding the sandbox attribute is enough to severely lock down an iframe. " rel="nofollow">http://example.com">
You'll also want the CSP `sandbox` policy on the `src` page to guard against direct linking.
[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Re: Neatly Bypassing Content Security Policy
#23Oh, not CSP as in concurrency. Makes more sense now.
I came to read about how Node.js uses a single thread to bypass CSP...
Re: Neatly Bypassing Content Security Policy
#24Oh, not CSP as in concurrency. Makes more sense now.
If your Cloud Service Provider doesn't support Communicating Sequential Processes, would their Customer Service Personnel handle a Constraint Satisfaction Problem?
Re: Neatly Bypassing Content Security Policy
#25Great article. Why is CSP so under-utilized? Less than 0.2% of the top 1m sites[0]. Although only 9% use basic features like secure cookies, and 6% HSTS. [0] https://blog.mozilla.org/security/2018/02/28/analysis-alexa-...
TL;DR: a terrifying amount of sites legitimately end up using these unsafe features without realizing it.
The spec revisions are a little arduous, but in my experience the biggest problem is that any site big enough to start caring about CSP is also big enough to have a myriad of trackers and JS snippets that insist on using these unsafe features. Google Tag Manager might as well have been based on weaponized XSS payloads.
And now the technical problem is actually a human problem because some poor security schmuck has to convince a totally different team with a totally different reporting structure (those trackers likely go up into sales or marketing, possibly some random SEO contractor you've barely heard of!) to prioritize a pretty fundamental change.
Maybe the security person tries to walk up their reporting chain until the two converge, possibly at the CEO. But it sure sounds like you're trying to kill a feature for intangible goals (it may or may not prevent an XSS vuln, you say?). And the team that owns the feature will tell you they can directly attribute growth to the visibility they get from that feature.
Even when it isn't SEO's fault, a lot of sites legitimately use inline scripts in order to shovel some server-side JSON into the rendered HTML quickly where eventually some JS can access it for example. You can use DOM elements with data attributes, but that's probably not how it works today because that's not the obvious way to do it.
Re: Neatly Bypassing Content Security Policy
#26I’m confused. If you already have script injection on a website with script-src 'unsafe-inline' (!!!), what do you need to bypass? I guess for some very unusual types of websites it could be hard to get information out, but you’re otherwise free to perform any action within the site as the user.
You would need to bypass connect-src in order to exfiltrate data. Even if you are able to call fetch() on your endpoint through XSS, CSP would block the network request. So the iframe and webrtc methods in the article are geared towards bypassing that since connect-src would fallback to default-src in this case.
Re: Neatly Bypassing Content Security Policy
#27Mods, can you please update title to clarify that "CSP" means "Content Security Policy" here?
Re: Neatly Bypassing Content Security Policy
#28Mods, can you please update title to clarify that "CSP" means "Content Security Policy" here?
[deleted]
Re: Neatly Bypassing Content Security Policy
#29Mods, can you please update title to clarify that "CSP" means "Content Security Policy" here?
Sure thing!
Re: Neatly Bypassing Content Security Policy
#30Great article. Why is CSP so under-utilized? Less than 0.2% of the top 1m sites[0]. Although only 9% use basic features like secure cookies, and 6% HSTS. [0] https://blog.mozilla.org/security/2018/02/28/analysis-alexa-...
I think that's easy: CSP is under-utilized in big sites because it can be hard to transition existing big sites to it. The URL you reference only focuses on "big" sites, which are pretty much always existing sites. Using CSP properly means removing all inline JavaScript and CSS, which is a lot of work and takes a lot of time. Note that this report doesn't give credit if a site uses CSP but allows unsafe-inline (see its footnotes for details).
That said, that report also notes that there is growth. A site I manage, https://bestpractices.coreinfrastructure.org , does use CSP in practically every page. There's one page where we had to weaken the CSP requirements, but that page doesn't include any data directly created by a user (so the risk is not low). The most recent version of CSP has some features that may make transition easier (once sites believe they can depend on it). There's reason to hope that CSP will become more common, but it's going to take time.