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: Mark S. Miller <erights@google.com>
Date: Sun, 7 Jun 2009 16:18:31 -0700
Message-ID: <4d2fac900906071618x3066b691v6bcb0df12c1f9892@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: public-webapps <public-webapps@w3.org>
On Sun, Jun 7, 2009 at 3:54 PM, Adam Barth <w3c@adambarth.com> wrote:

> GET really doesn't have anything to do with it.  The attacker can
> issue POST requests (and really any other method) too.  Note that the
> attacker can read the response and follow any links, etc.

Recall that we were examining the GET hypothesis under the assumption that
POSTs were already protected by secret tokens against XSRFs.

> If the starting point is not guessable, then I don't understand your
> > example.
> Virtually all sites have a well-known starting point, aka the home page.

On Sun, Jun 7, 2009 at 3:24 PM, Adam Barth <w3c@adambarth.com> wrote:

> I certainly believe a site can deploy secret tokens correctly.  I just
> think its a lot of work to get right.
> > To make progress, we should seek to lower the expertise needed to use
> this
> > good pattern safely, so that it can come to be used by less "advanced"
> > sites.
> That sounds like a promising direction.  Do you have a proposal for
> how we should do that?

> I don't see how this is useful if we're ignoring Caja-style mashups.
> The XSS attacker will simply use whatever API sends the header.

One proposal is http://waterken.sourceforge.net/web-key/
There are many partial variations of this idea already deployed.
They do not depend on any Caja-like technology. Neither does Caja depend on
them. Together they would make for a web much simpler to use safely than our
current mess.

On Sun, Jun 7, 2009 at 3:28 PM, Adam Barth <w3c@adambarth.com> wrote:

> On Sun, Jun 7, 2009 at 3:21 PM, Mark S. Miller <erights@google.com> wrote:
> > If the hypothesis I am raising is indeed not a problem, then it doesn't
> > matter whether these same origin requests carry "Origin: null" or
> nothing.
> > What matters is that JavaScript code have a standard way to request their
> > browser to issue requests carrying no other credentials, even if back to
> the
> > same origin.
> Yeah, I can see that as being useful.  I encourage you to propose a
> new API that does this.  The Origin-header-as-CSRF-defense already
> provides for this possibility.  Is there something specific you'd like
> me to change in the I-D to support this new API?

Yes. I will take you up on this invitation. Thanks!

Received on Sunday, 7 June 2009 23:19:06 UTC

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