[whatwg] Clickjacking and CSRF

[Aryeh Gregor]

I'm CCing wikitech-l here for broader input, since I do think
Wikipedia would be interested in adopting this but I can't really
speak for Wikipedia myself.  The history of this discussion can be
found in the archives:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/021133.html

I think both whatwg and wikitech-l are configured to bounce messages
by unregistered users.  For wikitech-l members who want to comment,
the registration link for whatwg is:

http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org

I'd suggest the discussion be continued on whatwg and people not post
replies to wikitech-l, to avoid confusion.

On Tue, Jul 21, 2009 at 6:34 PM, Brandon Sterne<bsterne at mozilla.com> wrote:
> I have two competing instincts in response to this proposal.  In
> general, I am opposed to adding a mechanism which effectively
> disables all the security protections offered by CSP.

Why?  It would most likely only be enabled temporarily.  Even if it is
enabled permanently (like all those sites with eternal SPF soft fail .
. .), it would be no worse than no CSP at all.

> Would it be possible for Wikipedia to leverage its community to help
> convert pages to support CSP?

Sure, but we have to have a list of things that are broken first.  I
think it would be much easier to get such a list if we could get it
from the clients themselves.  Then we would be enabling a totally
harmless feature (reporting only), verifying that no more errors are
being generated, and then enabling another feature that's already been
verified to not cause a significant number of errors.  We could
confidently enable reporting as soon as the first Firefox dev builds
shipped with CSP support.  I would be happy to personally commit that.
 Then we could enable real protection as soon as the reports got down
to an acceptable level.

If we had to just hope we had caught everything important and wouldn't
break anything, I think deployment would have to be a *lot* more
cautious.  The only thing we'd know is that we'd break lots of stuff,
but we wouldn't know what.  I certainly would never commit any code
like that without approval from the sysadmins, and I strongly suspect
they'd be hesitant to grant it.  It's not that the site would go down
or anything, but some scripts a lot of people are relying on would
probably break; and worse, we'd have lots of little separate
complaints from lots of different people going on for a long time as
more minor broken scripts get noticed.

I might be overestimating the potential risk here -- Wikipedia doesn't
really depend on JavaScript for almost anything -- but I'm *quite*
sure that it would greatly simplify deployment if we could be sure we
wouldn't be breaking anything.  It's not my decision, though.
Hopefully some higher-ups can comment here.

> It seems, based on the above, that you'll
> need to serve users custom CSP policy based on which scripts they have
> enabled, so it will probably be necessary to distribute the testing of
> CSP across the community.  Is it reasonable to expect the site admins to
> process all of the CSP violation reports on behalf of all the users?
> Wouldn't it be more scalable to have community members fixing the CSP
> violations and in the process have users protected from true XSS attacks?

If we could do reports only, then we would probably publish the data
live in some form, yes.  Then community members could fix it to the
extent possible.  Community admins could fix the problems on the
wikis, and developers could fix the problems in the software.  But we
need a list of what to fix.  The software is hundreds of thousands of
lines, and we have an enormous amount of user JavaScript:

mysql> SELECT SUM(page_len) FROM page WHERE page_namespace=2 AND
page_title LIKE '%.js';
+---------------+
| SUM(page_len) |
+---------------+
|     103877387 |
+---------------+
1 row in set (6.61 sec)

That's almost 100 MB of (presumptive) user JavaScript on the English
Wikipedia alone.  We can't possibly review all of that thoroughly
enough to be reasonably certain in advance that we won't get
significant breakage.

> I am not totally opposed to your proposal, though I would like to
> exhaust other possibilities before we defang CSP to such an extent.

I don't understand why this would be defanging anything.  It would be
entirely optional.  Am I missing something?