710273 - Implement CSP directive to disallow user-supplied scripts from executing in the context of the page

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Comment 1

[Brandon Sterne (:bsterne)]

(premature submission there...)

We want to let sites opt-out of the dev tool features that allow users to run JavaScript in the context of the page.  The goal is to thwart the "self-XSS" attacks we are seeing on various social networking sites.  To that end, let's add a Content Security Policy directive that indicates this preference, and the relevant dev tools implementations can check for this preference before executing script.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Will it be possible to override this (somehow, perhaps not in the default configuration)?

Comment 3

[Kevin Dangoor]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #2)
> Will it be possible to override this (somehow, perhaps not in the default
> configuration)?

Yes. See bug 664589 comment 34.

Comment 4

[Brandon Sterne (:bsterne)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #2)

Kevin already covered this, but yes, this will be overridable via (most likely) a hidden pref for users who want to turn off the safety catch.  I should have included this in the original summary.

Comment 5

[Frederic Eichinger]

Are we sure we really want to add this to the protocol?

Fundamentally, what we have here is consumers using a tool intended for developers, and messing up with that because they don't know what they're doing. So, the problem is really just that users do stuff they shouldn't do. So why even give them access to these tools?
Hide the console and other dev tools behind an "I am a developer!" switch in the settings - it should be a global setting anyway and not just per-site - but don't put this into the protocol. A protocol should define transfer and content, not the behaviour at the end point.

Comment 6

[Joe Walker [:jwalker]]

(In reply to Frederic Eichinger from comment #5)
> Are we sure we really want to add this to the protocol?
> 
> Fundamentally, what we have here is consumers using a tool intended for
> developers, and messing up with that because they don't know what they're
> doing. So, the problem is really just that users do stuff they shouldn't do.
> So why even give them access to these tools?
> Hide the console and other dev tools behind an "I am a developer!" switch in
> the settings - it should be a global setting anyway and not just per-site -
> but don't put this into the protocol. A protocol should define transfer and
> content, not the behaviour at the end point.

A global "I am a developer!" switch has been discussed at length on many bugs. We're not going to do that because we care about teaching people how to develop for the web.

Comment 7

[Frederic Eichinger]

(In reply to Joe Walker [:jwalker] from comment #6)
> A global "I am a developer!" switch has been discussed at length on many
> bugs. We're not going to do that because we care about teaching people how
> to develop for the web.

I'm well aware of that. It doesn't, however, change the fact that the problem at hand is not primarily relevant to the site or the protocol, so fixing it there is simply the wrong approach. I get that we want to teach people to use the tools properly, but a per-site (or, in fact, per-request) trigger doesn't help with that. This is a universal problem, it just has more "potential" on certain sites.

We can't on the one hand say "We want to educate people." and then with the next step go "But people are too inept to do figure out what they're doing, so we need to prevent their errors on the protocol level."

Comment 8

[Joe Walker [:jwalker]]

(In reply to Frederic Eichinger from comment #7)
> (In reply to Joe Walker [:jwalker] from comment #6)
> > A global "I am a developer!" switch has been discussed at length on many
> > bugs. We're not going to do that because we care about teaching people how
> > to develop for the web.
> 
> I'm well aware of that. It doesn't, however, change the fact that the
> problem at hand is not primarily relevant to the site or the protocol

I don't have evidence that this is more than a theoretical problem for sites other than Facebook. So the primary problem is relevant to the site.

> so
> fixing it there is simply the wrong approach. I get that we want to teach
> people to use the tools properly, but a per-site (or, in fact, per-request)
> trigger doesn't help with that. This is a universal problem, it just has
> more "potential" on certain sites.

There are 2 forms of this attack. The short form that we've seen evidence of (which is limited to Facebook) and the long form which we have no solution for, nor is a solution possible.

Viability of the self-xss script is inversely proportional to length of the script. It seems that the Facebook 3-step script is at the limit of viability for widespread infection. Lack of attacks to WIN+R seem to back this up.

I'd like to see examples where people have followed longer scripts. But if people are willing and able to follow a 10-step script then none solutions proposed so far comes close to protecting us.

A 3-step script requires a pre-loaded clipboard, which means hosting of flash content.

A 3-step script also means you can't have a navigation step, so this is only a problem for sites that accept user generated content.

A site can stop attack by deleting the script (given the no-nav rule). So clearly this is a bigger problem with user-reposting, greatly hampering script deletion.

That fairly much explains why this is only a problem for Facebook. As far as I know they're the only site on the web that fits all these criteria.

So your assertion that this is a universal problem is true, but only if you're thinking of greater than 3-step scripts. But if you're doing that, then none of the proposed solutions works either.

> We can't on the one hand say "We want to educate people." and then with the
> next step go "But people are too inept to do figure out what they're doing,
> so we need to prevent their errors on the protocol level."

You're missing the landing page part of the solution, which pushes the 3-step script to being a 4/5-step script (depending on how you count), also making cross-browser scripts impossible.

The CSP solution allows particularly vulnerable sites to opt into a system which makes things a 7+step script. Given that some sites are more vulnerable than others this seems reasonable.

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.