6 ms·

Neatly Bypassing Content Security Policy

104 points by wlrm 8y ago

Jach 8y ago
TLDR: don't use 'unsafe-inline'. Good article though.
- zinckiwi 8y ago
  The clue is in the name, I'd have thought.
Someone1234 8y ago
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-top-1m-sites-2/#alexa-02-2018-footnotes https://blog.mozilla.org/security/2018/02/28/analysis-alexa-...
- throwawayjava 8y ago
  > 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.
  - iancarroll 8y ago
    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.
    - ubernostrum 8y ago
      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.
      - Jach 8y ago
        This has been my feature work for the past couple months (I work on an enterprise site builder, basically, with some users doing what you describe -- we need to support that but hopefully with a smaller/harder to misfire footgun). There's a lot of feature complexity even after you've simplified it down, and it's kind of maddening how much effort it is to just send an extra (correct for the context) string in the response headers. The spec versions are interesting to read too, as well as browser compatibility. Differences in interpretation of the spec lead to github issues which lead to browsers fixing things in the past few months that have been part of the spec for much longer. (And if you have a big chunk of IE11 users, "what's the point" is valid.) An example of a spec issue is that I'm working on adding an endpoint for the report-uri directive so we can log some metrics but the first thing you see when reading about report-uri is that it's been deprecated in favor of report-to, but literally no stable browser release supports report-to yet. It's also not really enough. https://github.com/tc39/proposal-frozen-realms https://github.com/tc39/proposal-frozen-realms is a useful extension, since it would allow frameworks to do what they need to set up everything but then lock down objects from further extension/abuse...
- sametmax 8y ago
  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.
  - Promarged 8y ago
    Actually CSP can also block content modifications by extensions. I frequently get CSP reports from browsers using plugins that want to insert something on my site. Some time ago I also got CSP reports that indicated the AdBlocker couldn't touch the site too...
- lozenge 8y ago
  Because most ad networks and analytics providers don't tell you what CSP header to add to work reliably. Partly because ad networks can rotate in ads/resellers/scripts from hundreds of companies. Also, the resulting header can be quite long delaying the first byte of content (for each resource on the page).
- yeukhon 8y ago
  Way too complex. Followed the development up until 2.0, and I was already lost. Take this as someone who was breathing on the spec almost every day for a year. Now reading the latest spec is like trying to understand kernel.
- lvh 8y ago
  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.
- dwheeler 8y ago
  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 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.
dnag 8y ago
Just adding the sandbox attribute is enough to severely lock down an iframe. <iframe sandbox src="http://example.com"></iframe> http://example.com"></iframe>
- mattbierner 8y ago
  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
- ChrisSD 8y ago
  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/Content-Security-Policy/sandbox https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
minitech 8y ago
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.
- alxlu 8y ago
  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.
zupa-hu 8y ago
TLDR: CSP can by bypassed if you don't use it on all responses, like error pages. This is of course not bypassing CSP.
dvirsky 8y ago
Oh, not CSP as in concurrency. Makes more sense now.
- djtriptych 8y ago
  * Stands in this line
- sullyj3 8y ago
  I assumed Constraint Satisfaction Problem
  - xenonite 8y ago
    I had the same thought. It would be good to adjust the headline accordingly.
- dboreham 8y ago
  I came to read about how Node.js uses a single thread to bypass CSP...
- stephengillie 8y ago
  If your Cloud Service Provider doesn't support Communicating Sequential Processes, would their Customer Service Personnel handle a Constraint Satisfaction Problem?
nebulous1 8y ago
It's almost like there's a clue in the name 'unsafe-inline'
jey 8y ago
Mods, can you please update title to clarify that "CSP" means "Content Security Policy" here?
- deleted 8y ago
  [deleted]
- sctb 8y ago
  Sure thing!
nailer 8y ago
What if they use unsafe-inline but still lock down frames via frame-src?
- alxlu 8y ago
  In this example it would still work since frame-src will fallback to default-src if not specified.
  - nailer 8y ago
    I don't think you're reading my question properly - I'm asking about when frame-src IS specified - but just in case it's me that's missing something. I'll reword my question. What happens if a site: - allows 'unsafe-inline' as a script-src - does not allow untrusted domains in frame-src ?
    - alxlu 8y ago
      In the example they have default-src set to ‘self’ ‘unsafe-inline’ That essentially means frame-src is set to that same thing since it’s not specified. So the bypass in the example would still work since it’s iframing the same (trusted) domain even if they explicitly specify frame-src.
      - nailer 8y ago
        i don't understand. If they set frame-src to an explicit list of domains they trust surely default-src becomes irrelevant and the exploit doesn't work? I'm testing it now and creating an iframe won't work.
        alxlu 8y ago
        Yeah if you set frame-src to something that doesn’t include the current domain then it should prevent loading an iframe from the same origin That being said, this technique might still work in theory on whatever domains you have specified in frame-src if it doesn’t include ‘self’. So if you’re foo.com and frame-src only allows bar.com. If you managed to get script into foo.com maybe you could put an iframe pointing to bar.com/reallylongorinvalid That being said I haven’t had a chance to try this out on my machine yet so I could be missing something Also it looks like their demo includes sandbox allow-same-origin and allow-scripts in its CSP.

104 points by wlrm 8y ago

Jach 8y ago

TLDR: don't use 'unsafe-inline'. Good article though.

zinckiwi 8y ago
The clue is in the name, I'd have thought.

Someone1234 8y ago

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-top-1m-sites-2/#alexa-02-2018-footnotes https://blog.mozilla.org/security/2018/02/28/analysis-alexa-...

throwawayjava 8y ago
> 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.
- iancarroll 8y ago
  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.
  - ubernostrum 8y ago
    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.
    - Jach 8y ago
      This has been my feature work for the past couple months (I work on an enterprise site builder, basically, with some users doing what you describe -- we need to support that but hopefully with a smaller/harder to misfire footgun). There's a lot of feature complexity even after you've simplified it down, and it's kind of maddening how much effort it is to just send an extra (correct for the context) string in the response headers. The spec versions are interesting to read too, as well as browser compatibility. Differences in interpretation of the spec lead to github issues which lead to browsers fixing things in the past few months that have been part of the spec for much longer. (And if you have a big chunk of IE11 users, "what's the point" is valid.) An example of a spec issue is that I'm working on adding an endpoint for the report-uri directive so we can log some metrics but the first thing you see when reading about report-uri is that it's been deprecated in favor of report-to, but literally no stable browser release supports report-to yet. It's also not really enough. https://github.com/tc39/proposal-frozen-realms https://github.com/tc39/proposal-frozen-realms is a useful extension, since it would allow frameworks to do what they need to set up everything but then lock down objects from further extension/abuse...
sametmax 8y ago
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.
- Promarged 8y ago
  Actually CSP can also block content modifications by extensions. I frequently get CSP reports from browsers using plugins that want to insert something on my site. Some time ago I also got CSP reports that indicated the AdBlocker couldn't touch the site too...
lozenge 8y ago
Because most ad networks and analytics providers don't tell you what CSP header to add to work reliably. Partly because ad networks can rotate in ads/resellers/scripts from hundreds of companies. Also, the resulting header can be quite long delaying the first byte of content (for each resource on the page).
yeukhon 8y ago
Way too complex. Followed the development up until 2.0, and I was already lost. Take this as someone who was breathing on the spec almost every day for a year. Now reading the latest spec is like trying to understand kernel.
lvh 8y ago
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.
dwheeler 8y ago
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 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.

dnag 8y ago

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

mattbierner 8y ago
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
ChrisSD 8y ago
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/Content-Security-Policy/sandbox https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

minitech 8y ago

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.

alxlu 8y ago
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.

zupa-hu 8y ago

TLDR: CSP can by bypassed if you don't use it on all responses, like error pages. This is of course not bypassing CSP.

dvirsky 8y ago

Oh, not CSP as in concurrency. Makes more sense now.

djtriptych 8y ago
* Stands in this line
sullyj3 8y ago
I assumed Constraint Satisfaction Problem
- xenonite 8y ago
  I had the same thought. It would be good to adjust the headline accordingly.
dboreham 8y ago
I came to read about how Node.js uses a single thread to bypass CSP...
stephengillie 8y ago
If your Cloud Service Provider doesn't support Communicating Sequential Processes, would their Customer Service Personnel handle a Constraint Satisfaction Problem?

nebulous1 8y ago

It's almost like there's a clue in the name 'unsafe-inline'

jey 8y ago

Mods, can you please update title to clarify that "CSP" means "Content Security Policy" here?

deleted 8y ago
[deleted]
sctb 8y ago
Sure thing!

nailer 8y ago

What if they use unsafe-inline but still lock down frames via frame-src?

alxlu 8y ago
In this example it would still work since frame-src will fallback to default-src if not specified.
- nailer 8y ago
  I don't think you're reading my question properly - I'm asking about when frame-src IS specified - but just in case it's me that's missing something. I'll reword my question. What happens if a site: - allows 'unsafe-inline' as a script-src - does not allow untrusted domains in frame-src ?
  - alxlu 8y ago
    In the example they have default-src set to ‘self’ ‘unsafe-inline’ That essentially means frame-src is set to that same thing since it’s not specified. So the bypass in the example would still work since it’s iframing the same (trusted) domain even if they explicitly specify frame-src.
    - nailer 8y ago
      i don't understand. If they set frame-src to an explicit list of domains they trust surely default-src becomes irrelevant and the exploit doesn't work? I'm testing it now and creating an iframe won't work.
      - alxlu 8y ago
        Yeah if you set frame-src to something that doesn’t include the current domain then it should prevent loading an iframe from the same origin That being said, this technique might still work in theory on whatever domains you have specified in frame-src if it doesn’t include ‘self’. So if you’re foo.com and frame-src only allows bar.com. If you managed to get script into foo.com maybe you could put an iframe pointing to bar.com/reallylongorinvalid That being said I haven’t had a chance to try this out on my machine yet so I could be missing something Also it looks like their demo includes sandbox allow-same-origin and allow-scripts in its CSP.