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 15:21:40 -0700
Message-ID: <4d2fac900906071521w427fb6b0k70f3a5f74b241a9a@mail.gmail.com>
To: Adam Barth <w3c@adambarth.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>, www-tag@w3.org
On Sun, Jun 7, 2009 at 12:17 PM, Adam Barth <w3c@adambarth.com> wrote:

> > On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@google.com>
> wrote:
> > Since malicious machines, or malicious applications running on trusted
> > machines, can sent messages that aren't self-identified as cross origin,
> why
> > do I suggest that lack of an origin header (in the absence of other
> > credentials) might lead a server into granting more access than it would
> for
> > messages self-identified as "Origin: null"?
> > [...speculation about firewall-based patterns...]
> This seems like a lot of speculation.  Do you have any evidence to
> support this hypothesis?

Only projecting from my experience of how bad security decisions are made by
those who think unclearly about how their firewall does and does not protect
them. I have no other evidence.

> > Under these admittedly fragile (but common) assumptions, a server may
> indeed
> > "trust" a message that doesn't identify itself as cross origin more than
> it
> > "trusts" one that does. Thus, a non malicious script that doesn't wish
> the
> > sanitized scripts it loads to "speak for it" should force all the
> messages
> > they initiate to be identified as "Origin: null".
> If this were the case, we'd have this same problem with Referer,
> postMessage, Origin-for-CORS, and numerous other web technologies.

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. Then, we can successfully encourage servers to honor requests
based only on authorizing information explicitly placed into the payload of
these messages -- such as the current use of secret tokens for XSRF
protection. If there's any reason for the non-uniformity you suggest, I
agree that the remaining danger of encouraging unsafe server behavior would
probably be small enough to live with. But what would this compromise

Received on Sunday, 7 June 2009 22:22:17 UTC

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