Live data from Hacker News

Neatly Bypassing Content Security Policy

lab.wallarm.com

1–10 of 38 posts

Re: Neatly Bypassing Content Security Policy

#4

Great 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-...

> Why is CSP so under-utilized?

I think a few reasons:

1. It's not a sufficient replacement for sanitizing input. You need to sanitize; CSP is just an extra layer of protection.

2. relative new.

3. many popular frameworks don't support it out of the box.

Re: Neatly Bypassing Content Security Policy

#6

Great 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-...

> Why is CSP so under-utilized? I think a few reasons: 1. It's not a sufficient replacement for sanitizing input. You need to sanitize; CSP is just an extra layer of protection. 2. relative new. 3. many popular frameworks don't support it out of the box.

The deployment difficulty is also high, especially for what it offers. Deploying CSP on anything non-trivial involves a lot of coordination with basically anyone who runs code on your site.

Re: Neatly Bypassing Content Security Policy

#7

Earlier quoted context omitted.

> Why is CSP so under-utilized? I think a few reasons: 1. It's not a sufficient replacement for sanitizing input. You need to sanitize; CSP is just an extra layer of protection. 2. relative new. 3. many popular frameworks don't support it out of the box.

The deployment difficulty is also high, especially for what it offers. Deploying CSP on anything non-trivial involves a lot of coordination with basically anyone who runs code on your site.

This is the big one.

Lots of sites have marketing departments which like to switch out their advertising, engagement, A/B testing, etc. code on a regular basis. Which in turn requires either changing the CSP frequently to accommodate, or else opening holes in the CSP to allow marketing to just copy/paste inline JS and other badness. At which point it's hard to justify CSP.

Re: Neatly Bypassing Content Security Policy

#8
post #5

Just adding the sandbox attribute is enough to severely lock down an iframe. " rel="nofollow">http://example.com">

Just to add some context: 'sandbox' will make the iframe load in a unique origin and also disable scripts (along with disabling bunch of other things). This will prevent these attacks.

There's also ' frame-src' for content security policies, which lets you control what is allowed in the iframe's src. Even with these guards in place, you generally should not let user content drive an iframe's src

Re: Neatly Bypassing Content Security Policy

#9
I’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.

Re: Neatly Bypassing Content Security Policy

#10

Great 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-...

It may also prevent tooling to work on your site. E.G: bookmarklet won't work anymore. On browsers without extensions, they are the only way to get extra features.

It's especially annoying on github.

Post reply on HN