Is CSP enough to prevent XSS attacks

Question

Assuming that users are using modern browsers, is implementing a strict CSP policy enough to prevent all XSS attacks?

I'm working on a Backbone app, and am wondering if I still need to be escape user data on the client to display all the time.

Answer 1

Content Security Policy (CSP) is just a one layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. However please bear in mind that security is all about defense in depth so yes you still should implement additional security layers and please remember that preventing Cross-site Scripting Attacks(XSS) vulnerabilities in all languages requires two main considerations:

• the type of sanitization performed on input
  
• location in which that input is inserted.
  

It is important to remember that no matter how well input is filtered; there is no single sanitization method that can prevent all Cross-site Scripting (XSS).

The filtering required is highly dependent on the context in which the data is inserted. Preventing XSS with data inserted between HTML elements is very straightforward. On the other hand, preventing XSS with data inserted directly into JavaScript code is considerably more difficult and sometimes impossible.

For the majority of PHP applications, htmlspecialchars() will be your best friend. htmlspecialchars() supplied with no arguments will convert special characters to HTML entities.

Another function exists which is almost identical to htmlspecialchars(). htmlenities() performs the same functional sanitization on dangerous characters, however, encodes all character entities when one is available.

strip_tags() should not be used exclusively for sanitizing data. strip_tags() removes content between HTML tags and cannot prevent XSS instances that exist within HTML entity attributes. strip_tags() also does not filter or encode non-paired closing angle brackets. An attacker may be able to combine this with other weaknesses to inject fully functional JavaScript on the page.

addslashes() is often used to escape input when inserted into JavaScript variables.

Answer 2

Assuming that users are using modern browsers, is implementing a strict CSP policy enough to prevent all XSS attacks?

Not all modern browsers implement CSP (IE has only very limited support). But assuming that the browser has proper CSP support and that you CSP is very strict (no unsafe-eval!) then it can be used to successfully prevent XSS. But...

I'm working on a Backbone app, and am wondering if I still need to be escape user data on the client to display all the time.

There are other attacks apart from XSS. If you don't escape properly then HTML injection can still be used to affect the parts of the page which are not covered by CSP, like:

• Include links (<a href=...) which point to attacker-controlled resources. Depending on the page also existing links might be changed.
• Include new forms or change the submission target for existing forms. This way you could grab sensitive data.
• Redirect the user to drive-by-downloads by including HTML using meta refresh.
• an possible more

Answer 3

No - this is partly due to browser support. For example, Internet Explorer only partially supports Content Security Policies.

Also, a CSP should be seen as an effective secondary solution for XSS. Think of it as protecting against code where the developer has forgotten to output encode correctly. This will protect your application in supported browsers while the fix is created and before it is deployed to your production systems.

Correctly encoding output ensures that web standards are followed, which increases both security and functionality. For example, you would not want your web application to display incorrectly if the user has decided to put <> characters in their input.

Additionally, it may be possible for nefarious users to break your site in other ways, despite the CSP. For example, including other scripts from allowed sources, or including your scripts twice to create a Denial of Service for others users where the output is displayed (as the duplicate breaks the page logic). An attacker would also be able to edit your site content in other ways.

In summary I would advise against using additional security features in order to cut corners elsewhere. They should be complimentary - always think defence in depth.