0

I'm trying to understand why certain CSPs block inline javascript. Is the concern that a user will be able to insert javascript that will then be served to other users? If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site? How is this a CSP problem?

Daniel B
  • 441
  • 1
  • 3
  • 10

2 Answers2

1

If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site?

It is actually very common that users have the ability to serve their own content. Just have a look at all the social networks and public blog sites where users can provide their own content within a site they don't own.

How is this a CSP problem?

Usually the content added by users gets sanitized, i.e. script and other things are removed. But, this sanitizing might have bugs. CSP offers an additional line of defense: if CSP disallows inline script no inline script will be executed even though some inline script might have bypassed the sanitizing.

Steffen Ullrich
  • 201,479
  • 30
  • 402
  • 465
0

Is the concern that a user will be able to insert javascript that will then be served to other users?

Yes, and that JS can do whatever it wants, just like a full script tag, with a few minor inconvenient syntax restrictions.

If so, isn't this an issue with the fact that a user somehow has the ability to serve whatever they want to users from your site?

Yes, you don't want that happening at all, CSP or not. You want to convey the user's intent, not republish the user's input. CSP is not the front line of defense, it's a backup to mitigate the harm from mistakes like not enough sanitizing, too-smart template engines, and plain bugs.

How is this a CSP problem?

It's content, and it relates to security, so the Content Security Policy is a good place to address the issue, right?

dandavis
  • 2,693
  • 11
  • 16
  • In what situation would preventing only inline JS or event handlers provide a level of protection? If a user can insert arbitrary HTML, can't they just insert a – Daniel B Oct 08 '17 at 06:01
  • in the situation where you manage html safely, typically using a CMS or subset like markdown to accept incoming user content. The script tag attack is well-known and defended already. You are right that some parts of the CSP standard don't make much sense in complete isolation. – dandavis Oct 08 '17 at 06:03
  • 1
    @DanielB: If you use a CSP that allows loading script from foreign sites, you've screwed up [your attempt to write a secure CSP]. If you use a CSP that allows inline script, you've screwed up. If your CSP both prevents loading foreign scripts, AND prevents inline scripts, (*AND prevents eval, etc.) then you've become nigh-invulnerable to XSS, at least for CSP-supporting clients. If you leave any of those protections out, you may be vulnerable to XSS. Of course, other non-script insertion attacks may still work, and some people still use IE11, so you still need to secure your user input. – CBHacking Oct 09 '17 at 07:12
  • @CBHacking Thanks! That makes sense. It just feels like such a weird rule to have in isolation, like if you separated the rule for having nonces into 'has-nonce' and 'actually-checks-if-nonce-is-valid". – Daniel B Oct 09 '17 at 07:18
  • 1
    @DanielB No prob. The reason for the fine-grained rules is mostly to enable partial restriction for backward compatibility. For example, let's say you have an existing site that loads all its scripts from trusted sources (so you can set their sources in CSP and disallow all others), but also uses inline event handlers (so you cannot disallow inline script). This is less secure, but means you can be secure against a situation where somebody can inject a <script> tag but not, for some reason, an event handler (perhaps your input filter rejects = characters). Slightly better than nothing. – CBHacking Oct 09 '17 at 07:32