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

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
today).

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
defense.

> 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.

Adam

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