XSS - 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

No, CSP is not a magic bullet. It should be one line of defense, not the entire defense. If properly configured it can help

• preventing usable XSS where the payload, whether persistent or reflected must be small and therefore would usually just create a script element and inject external code
• avoiding data extraction and misuse as platform to attack other sites. Depending on how your application works, access to your backend service may suffice to extract data, for instance, if your users can write blog posts an attacker could create a new post with the data it needs to extract, wait for a signal that the data has been grabbed (via a comment for instance) and delete the post again, all without communicating with external servers.

Answer 2

To answer the question, yes a modern browser with default-src 'self' can still execute user-controlled javascript: JSONP .

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.

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

Answer 3

CSP should not be used as the only way to prevent XSS attack. This mechanism works only client side (If you save malicious data into your DB, then you can probably start infecting other systems that you integrating with) and it's not implemented by all browsers ( http://caniuse.com/#search=csp ).

To prevent XSS you should always validate input data and encode output data. You can also print warning message in JavaScript console to prevent somehow Self-XSS attacks (ex. open facebook page and turn on Chrome Developers Tools - look at the message in console).

Remember that the user input on the website is not the only source of XSS. Malicious data can also come from:

1. Importing data from files
2. Importing data from third party systems
3. Migration data from old system.
4. Cookies and http headers.

If you have appropriate validation and encoding of data (server side), then you can additionally apply browser mechanism such as: CSP, X-XSS-Protection or X-Content-Type-Options to increase your confidence about your system safety.