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 that I would generally advise against. However I don’t think that fixing this 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.

How to Eat an Elephant

This is about levels of change. It’s partly about hg.mozilla.org vs GitHub (or BitBucket). But it’s more about our devt/review/commit process.

Moz-central demands patches that solve significant issues, and it’s probably right in wanting this, but this bite size comes with problems.

There are 3 levels of change worth discussing:

  1. The detail level we’re used to working at: ’Added foo’, ’Renamed foo to bar’, etc. If working in a small team, this is probably the level we would commit at. At this level it’s easy to understand the intent behind each change.
  2. The review level which is an ideal chunk for someone to review. You probably don’t want to review every new commit as it’s done, but on the other hand, you don’t want to be told that you made a mistake weeks ago and need to redo lots of work. So ideally this happens on something like a daily basis. It’s the scale that pull requests were designed for.
  3. The patch level which mozilla-central is used to, and which is ideal for commit. The work is ‘done’ and useful for a much wider audience. When a bug is fixed we can extract a patch to be committed, like this one for bug 684958.

The problem with the Mozilla process is that steps 1 and 2 don’t exist at all. The benefits to the existence of more detailed change levels are:

  • Review is faster and deeper. You can review this pull request far better than a conventional patch because you can see what I’m intending by each change - you don’t need to reverse engineer the intent and mentally hold together all the bits of mashed together bits of intent.
  • Smaller changes are easier. Our current process prevents us from clearing up small things that are not directly related to the bug in hand. We can (for example) entertain the thought of variable renaming because it won’t confuse the patch. There may be other reasons not to go crazy with this, but at least the process won’t be one.
  • Progress is visible. Because we can share to a smaller team before we’re done, everyone gets to see what’s happening. There is a feeling of momentum - progress is the norm. Just like a 6-week cycle is better than an 18-month cycle, a daily commit/pull cycle is better than a weekly patch/review cycle.

In effect we’re using GitHub as a tool to develop patches for Firefox, rather than to develop Firefox itself. In some ways I mean this literally.

There are probably reasons why the detail of what works for GCLI might not exactly work in other places, but I’m willing to bet that these ideas could be adapted to be of more general use.

Fundamentally we solve big problems by breaking them down into smaller steps.

I can eat an elephant, but not by opening really wide.