What are the limitations of Content Security Policy?

Question

I'm wondering what this new technique will not protect us against.

As I see it, since inline scripts are disabled (and I assume that includes javascript: links) then it solves the issue of covert theft of sensitive data via auto-executed JavaScript.

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website.

Is this accurate, or are out-links prohibitable also?

There may be tricky ways to capture sensitive data in an external resource call as well, as I am not familiar with the scope of CSP.

What is the scope of a would-be XSS attack with the presence of a tight CSP?

Edit: updated assumptions for the purpose of this post:

• Users have a CSP 2 capable browser.
• Inline style= is still going to be allowed by the policy. style-src ... unsafe-inline
• We will only allow resources to be loaded from domains we control. (no external images)
• We run our own CDN, so that domain has no 3rd-party content, and fits the same security standards as the main domain.

Answer 1

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website.

Is this accurate, or are out-links prohibitable also?

Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team considers XSS without actual content injection (e.g. injecting into an unquoted tag attribute context) to be lower priority than a content injection bug itself because of CSP. We are blessed with having virtually no users on browsers that don't support some form of strong CSP.

What is the scope of a would-be XSS attack with the presence of a tight CSP?

Forgive me here if this sounds soapboxy, but your question does not define "tight CSP", so let me elaborate on some things many overlook.

For the sake of argument, let's say this is a policy that is proposed (line breaks added for clarity, this is not a valid header):

Content-Security-Policy: default-src 'self'; img-src https: data:; connect-src paypal.com api.example.com; script-src 'self' ajax.googleapis.com; style-src 'self' 'unsafe-inline'

Note: removing unsafe-inline from style-src is not practical today.

That's a pretty good policy with some obvious and not so obvious flaws, but inline script is not allowed. There are many more caveats to consider with CSP, it's not just about disabling eval and inline script (yes javascript: and on* event handlers are included).

Locking down 3rd parties to actually limit XSS

• "CSP Bypasses" are a thing. H5SC Minichallenge 3: "Sh*t, it's CSP!". We allow a 3rd party cdn which opens up XSS.
• CSP: bypassing form-action with reflected XSS form-action is not covered by default-src 'self' since it is not a "fetch directive".
• Data exfiltration via injected content tags (e.g. img, style, etc) where policies tend to be more relaxed. We allowed exfil via the image tag.

So many other vectors still exist

GitHub's CSP journey contains many points on how the policy was tuned to prevent certain attacks.

All of the below can be abused with the proposed policy.

• Removing 'self' from script-src to prevent XSS via JSONP
• Exfiltrating CSRF tokens via img and form tags
• Moving hosted flash files to a different origin instead of 'self' because flash ruins everything.
• Using dynamic policies to prevent unexpected use of APIs that should only be used from a specific set of pages.
• Limiting use of 'self' for frame-src/child-src
• Abusing the base tag.

Sometimes, CSP just doesn't apply.

It's possible to circumvent CSP entirely. See PDF content-type sniffing for an example where user-controlled data on a page can really mess things up.

There's literally nothing we can do about this from CSP's perspective.

And sometimes, the internet makes you cry.

See Stealing the pie without touching the sill where CSS can be used to steal AND exfiltrate data on a page without javascript.

Because removing 'unsafe-inline' is not practical, this attack is possible. However, this attack is difficult to execute.

Answer 2

We need to consider exactly what a tight policy is. I have identified three levels:

Level 1 - Stop XSS

At this level, a tight policy will stop all XSS. If the site has XSS flaws, these will not be exploitable (assuming the user's browser supports CSP).

An XSS attacker could still reference resources on their own server, which creates a web beacon. They can see users' IP addresses, and deliver malicious content (e.g. exploiting image rendering bugs). They can also redirect forms, potentially creating a highly-realistic phishing form.

Level 2 - Stop beacons

At this level, all embedded resources can only be loaded from trusted sources, so web beacons are not possible. Form actions are also restricted, so direct form redirection is not possible.

An XSS attacker can still change the page contents and layout. This includes embedding malicious links. I'm not convinced this is a major phishing risk though: savvy users will check the address bar before entering credentials, and non-savvy users will fall for much simpler tricks.

Level 3 - Stop inline CSS

This reduces an attacker's ability to change the page layout - although they can sill control content and inject links.

CSP Auditor

I created the CSP Auditor tool to help assess policies. It only assesses whether policies meet level 1. It turns out that the majority of major sites with CSP have a policy that does not meet level 1. Levels 2 and 3 will be even harder to achieve - so much so, I'm not putting checks in the auditor (for now at least).

Answer 3

CSP protects you against many script driven attacks. Your belief that "solves the issue of covert theft of sensitive data" isn't accurate. It may solve the issue of covert threat via scripts in that page, but it doesn't, for example, solve cross-tab issues, or proxy manipulation.

More broadly, there is no complete list of attacks, and so trying to enumerate "I'm wondering what this new technique will not protect us against" is an infinite set.