W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 7 Jun 2009 12:12:53 -0700
Message-ID: <7789133a0906071212o3664123cl7069ad315515ff4f@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Thomas Roessler <tlr@w3.org>, Tyler Close <tyler.close@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>, Google Caja Discuss <google-caja-discuss@googlegroups.com>, Douglas Crockford <douglas@crockford.com>, Tyler Close <tyler@waterken.com>, Collin Jackson <collinj@cs.stanford.edu>, Collin Jackson <collin.jackson@gmail.com>, David Wagner <daw@cs.berkeley.edu>
Hi Mark,

Thanks for your feedback.  At a high level, you seem concerned about
very advanced sites (e.g., ones use object-capability mashups).  The
Origin-header-as-CSRF-defense is aimed at making CSRF defense easier
for simple sites.  Just like you need to do complex gymnastics to
avoid XSS when running untrusted JavaScript in your security origin,
you'll also have to use one of the more complex CSRF defenses, such as
secret tokens, in these cases (just as you need to do for all sites

Detailed comments below..

On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@google.com> wrote:
> I admit that I haven't followed in detail the various origin
> proposals (cors, html5, ietf (withdrawn?)). I am glad to see that
> people want an origin proposal with good security
> properties. However, I fear all the current proposals amplify one of
> the browser's worst security hazards -- abuse of ambient authority
> creating confused deputy hazards. The current browser same origin
> policy already has plenty of these problems
> <http://waterken.sourceforge.net/aclsdont/>.

For better or worse, that's the security model we've got.  Worrying
about this for the Origin-header-as-CSRF-defense is a bit like horse
is gone (to borrow a cliche).  Almost all browser security features
have this behavior.  For example, cookies, the Origin-header-for-CORS,
postMessage, localStorage, window.open, the password database, etc.

> To be concrete, pages contain content -- whether mashups, gadgets, or
> simple libraries -- whose authorship does not correspond to the
> browser's notion of origin. As Crock said in his w2sp keynote
> <http://w2spconf.com/2009/presentations/keynote-slides.pdf>, "A mashup
> is a self inflicted cross site script." The problem isn't the mixing
> of scripts representing different interests. The problem is that all
> scripts that execute on a page are implicitly allowed to exercise all
> the authority that this browser associates with that page's origin.

Getting the security right for mashups that run untrusted script in a
trusted security origin is really tricky, as I'm sure you're quite
aware.  Fortunately, the vast, vast majority of web sites don't have
to worry about these issues.  These web sites, however, do have to
worry about CSRF.  The goal of the Origin-header-as-CSRF-defense is to
provide low-cost way for sites to mitigate CSRF vulnerabilities.  A
site that's doing some complicated Caja-style mashup has already
bitten the complexity bullet and will need to use a complex CSRF

> How do these origin proposals amplify this hazard? The main (only?)
> motivation for the origin header is to enable servers to make
> allow/deny access decisions on cross-origin requests based on the
> presented value of the origin header. This means that a script running
> on a page from origin A can now make a cross-origin request to a
> server at origin B and exercise the authority that this server
> associates with origin A. If some of these origin proposals still
> allow the browser to present the credentials (e.g., cookies) that
> browser associates with B, then, despite protestations to the
> contrary, we have also failed to address existing XSRF dangers.

You're assuming that origin A is using a complex Caja-style mashup.
We're not after that use case.  The Origin-header-as-CSRF-defense
doesn't make A or B's job any harder.  It just makes life easier in
the common case.

> Three proposals I've seen in these threads, if combined and extended,
> point towards a solution.

[Snip long proposal to introduce a XMLHttpRequest3 that always sends
an null Origin header.]

This proposal is compatible with the Origin-header-as-CSRF-defense.  I
drafted the requirements to allow for this kind of future innovation.
In particular, the user agent is always allowed to send Origin: null
if the UA thinks that's a good idea.

Received on Sunday, 7 June 2009 19:13:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC