Combating Self-XSS

What is Self-XSS?

Dr. Evil has several options for getting his script to execute in the page of another site. Generically we call this XSS. Self-XSS involves using social engineering to coerce a user into manually executing JavaScript using the location bar or developer tools. For more, see socially-engineered XSS attacks.

The recent Facebook attack signals that something needs to be done, but knowing the right response is tricky.

What is Mozilla doing about it?

We're proposing adding a directive to CSP that says 'Please disallow user supplied JavaScript in the context of this resource'.

It will probably look something like this: 

X-Content-Security-Policy: no-user-js

We're also going to add a way for developers to opt out of this protection. Effectively saying 'I can take care of the JavaScript that I ask my browser to execute'.

How does this affect other Firefox developer tools?

It doesn't. The Highligher, Style Inspector, Style Editor and Tilt are all unaffected. This is only about JavaScript executed via the Web Console and Scratchpad.

How does this affect users?

User Is a developer?
No Yes
Can recognize Self-XSS attack? No Added Self-XSS attacks protection. Warned about Self-XSS, may benefit from protection.
Yes Unchanged Minor inconvenience of having to set a preference (one time only) to enable user JavaScript on sites using this Self-XSS protection.

I think this is a fairly clear net win: Minor, one time only, inconvenience to a sub-set of web developers, vs. full-time protection for the many that wouldn't recognize a self-xss attack.

Objections: This is a user problem

The goal of educating 7 billion people about what JavaScript can do is lofty, grandiose, ambitious and utterly unattainable. There has to be another solution.

Objections: This is a Facebook problem

While it's true that allowing untrusted, unvetted, third party, dynamic content onto your site is something to avoid, I don't think that fixing this either is going to happen, or would fix the problem. The attack could easily forward you to another site to see the clipboard injecting flash, before returning you to the original site for the 'paste' step.

Objections: This is a Flash problem

While it's true that Adobe's clipboard policies are more relaxed than those of major web browsers, we've seen people caught by instructions that ask people to select/copy their own attack script. We think that the level of pain caused to developers by the CSP solution is low enough that we can justify the additional protection.

Translation

Пост доступен на сайте softdroid.net: Что такое Self-XSS, или межсайтовый скриптинг.

Posted by Joe Walker

Comments

Tom Sepez

I like the proposal, but wonder if the syntax should be script-src: 'no-user' ... anticipating that sites that want this will also have a script-src directive.

That sounds like a good idea. We need to make sure that it fits with the opt-in / opt-out semantics of script-src.

Please include an option in preferences with some scary text such as "I don't care about becoming a victim of socially engineered attacks, neither about being infected by malware, opt me out from every security policy including future ones" to disable or restore every feature added or removed because of socially engineered attacks and you have my vote in favor.
Unfortunately Firefox is becoming more and more uncomfortable for developers and power users with every security-related downgrade (because there's no way to call them updates), specially because the development team never provides a way to get the old behavior back "for the sake of security".

about:config provides lots of prefs to turn security features off, and this will be another.

Ew. Please don't break the Web Console. I actually vastly prefer it to Firebug, and making it disable-able out of the box is goofy. People who would do this will also do pretty much anything a website tells them to. This is an education problem.

We think that the large majority of sites will not use this csp directive unless they detect a problem with self-xss. So you will be largely unaffected, and even when affected as a developer you have only to set a pref once to be totally free of this restriction.
Educating 7 billion users is virtually never a practical option.

I believe that part of Mozilla's mission is to remind the everyday user that the web is interactive, and to encourage hacking and remixing. Projects like Hackasaurus reaffirm this. I reject things like Safari hiding their developer functionality behind an "advanced" preference, and this feels like a step in that direction.

We're all unanimous that we don't want to go the Safari way. Here's why this is different:
  • This should rarely take effect - only on sites with self-xss problems, which today is mostly just large social networks
  • Even when it does, we're planning on hiding nothing, instead showing a link to an MDN page with an explanation, and instructions on disabling

1. Go into options and enable user js
2. Run attack
Only way around this is to make the disable option something like a compilation option, but then it goes from a minor inconvenience/pain to a major.
I find this so easy to engineer around, that i think it adds more pain then it adds protection, and a better solution should be looked at.

We can't protect against all levels of zombie behavior, but our indications are that writing Self-XSS instructions to go into about:config is likely to be complex enough that the majority will get bored or confused before they complete the task. So many people will be saved.

JulienW

I do agree this is a real problem. But then I have two questions :
- Why do you forget javascript from bookmarklets, and from javascript: URLs in the address bar ?
- And why doing things differently for the sites which don't have "X-Content-Security-Policy: no-user-js" ?

bookmarklets - The jury is currenly out on those. Our current plan is to leave them as they are. We don't have evidence that they are being used as a vector. If they do become a problem then we could include them with an opt-out at a later date.
javascript:URLs - Firefox already block javascript URLs. My understanding is that Webkit based browsers will be doing the same soon.
Why are we ignoring sites that don't have 'X-Content-Security-Policy: no-user-js'. Because we want to disrupt the web as little as possible, and because most sites don't need it. Currently this is overwhelmingly a problem for very large social networks.

Comments have been turned off on old posts