XSS and Content Security Policy

Question

Can XSS be prevented 100% by setting the content security policy as default-src 'self'? Is there any way XSS can happen in that case? One possibility I can think of is injecting user input into one of your scripts dynamically at the server-side, do you agree? Are there any other vulnerabilities you can think of?

Answer 1

CSP in such a configuration should enable the following security measures:

• Disable inline scripts
• Disable inline styles
• Disable all use of dangerous JavaScript functions (e.g. eval)
• Force all content to be loaded only from the existing domain. This applies to:
  • JavaScript
  • CSS
  • Fonts (e.g. WOFF)
  • Ajax (XmlHttpRequest and similar)
  • WebSockets
  • Video
  • Objects (e.g. Flash, Java applets)
  • SVGs
  • WebGL assets
  • Frames
  • Images
  • Probably some other things I forgot...

As such, XSS should be possible only in cases where resources on the domain can be controlled by an attacker, as you mentioned.

You can lock CSP down further by setting default-src 'none', then explicitly enabling only content types which you are expecting to use on the site. This helps lower your attack surface further by disabling content types like Flash, Java applets, SVGs, canvas, etc. when you're not using them.

One additional vector you may not have considered is Path-Relative Stylesheet Overrides (PRSSI), otherwise known as Relative Path Overwrite (RPO) vulnerabilities. These work by exploiting URL handling behaviour in some CMS software, whereby path characters appear after a script are taken as parameters (e.g. example.com/wiki/index.php/Something shows the Something page). When a path-relative stylesheet is included (e.g. main.css rather than /main.css) this can be sometimes abused. In our example, because main.css is imported relative to the current path, an inclusion in the example URL above would cause the browser to try to load example.com/wiki/index.php/main.css as a stylesheet. If you can create a wiki page called main.css, this would allow you to control the content of that stylesheet, and potentially load malicious CSS (e.g. with the expression directive). You can do the same thing with path relative JavaScript imports. The fix here is to always reference content by its full canonical path.

Answer 2

default-src 'self' allows XSS via JSONP and content-type sniffing attacks:

Of particular note is our lack of self in our source list. While sourcing JavaScript from self seems relatively safe (and extremely common), it should be avoided when possible.

There are edge cases that any developer must concern themselves with when allowing self as a source for scripts. There may be a forgotten JSONP endpoint that doesn’t sanitize the callback function name. Or, another endpoint that serves user-influenced content with a content-type that could be sniffed by browsers as JavaScript. GitHub has several such endpoints. For example, we return commit diffs as text/plain.

http://githubengineering.com/githubs-csp-journey/