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

On Mon, Jun 8, 2009 at 10:24 AM, Tyler Close <tyler.close@gmail.com> wrote:

> On Sun, Jun 7, 2009 at 4:18 PM, Mark S. Miller<erights@google.com> wrote:
> > On Sun, Jun 7, 2009 at 3:28 PM, Adam Barth <w3c@adambarth.com> wrote:
> >> 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!
>
> For CORS <http://www.w3.org/TR/access-control/>, and other parts of
> web-apps, I think the above agreement is the important take-away from
> this discussion. For sites with advertising, or other third-party
> widgets, it would be nice to have a way for code to issue network
> requests without impersonating the hosting page's Origin.
>

First, I agree with Tyler that this agreement together with the agreement
just now with Anne are the important take aways. These agreements do not
depend on the outcome of the remaining XSS issue Adam and I are debating. I
suggest that discussion of how to turn these agreements into specs continue
on the "XHR without user credentials" thread. Those interested in what
upcoming specifications should say, rather than how many vulnerabilities can
dance on an XSS, can stop reading now.

I suggest that the debate about XSS risks continue here under the original
subject line since it describes the remaining issue we're still debating.


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

> On Sun, Jun 7, 2009 at 6:24 PM, Mark S. Miller <erights@google.com> wrote:
> > On Sun, Jun 7, 2009 at 4:29 PM, Adam Barth <w3c@adambarth.com> wrote:
> >>
> >> Right, but once the attacker has XSSed site A, the attacker learns the
> >> secret token necessary to issue the next request in the chain to site
> >> A regardless of the method.
> >
> >
> > Recall that this is in response to
> >
> > On Sun, Jun 7, 2009 at 2:53 PM, Mark S. Miller <erights@google.com>
> wrote:
> >>
> >> If servers at A don't freely hand out such tokens in response to
> guessable
> >> GET requests,
> >
> > So, if servers at A don't do this, how does the attacker, having XSSes
> site
> > A, learn the secret token necessary to issue the next request?
>
> The same way the user does: by generating a click event on whatever
> DOM element leads to the next page.
>


Under any system which presents ambient origin credentials to authorize
access, whether http auth info, cookies, or identiied Origin headers, an XSS
against page X on origin A can abuse all that user's authority associated
with *origin A*.

In a pure secret token based system, an XSS against page X on origin A can
abuse all the authority held by *page X* -- the authority authorized by the
secret tokens that page X knows and all authority reachable by guessable
traversal from X starting from knowledge of these tokens. If A's website is
structured according to both RESTful and POLA (Principle of Least
Authority), then most of A's pages will hold less much less authority than
the authority associated with A as a whole.

This argument is exactly parallel to the "Solitaire" criticism of
conventional ACL-oriented OSes <
http://video.google.com/videoplay?docid=-7961423532989255419>. Just as a
desktop Solitaire appication does not need the authority to delete your
files, a web Solitaire game running on gaming site A does not need authority
to delete all the other games (or whatever) you have in progress at that
website. Just as a conventional OS grants Solitaire this authority it does
not need, conventional web credential systems grant to the web Solitaire
game all your authority at that site/origin. If either Solitaire has an
exploitable vulnerability, then the attacker can abuse this excess
authority.

However, if either Solitaire -- the application or the web page -- only
holds the authority it needs to perform its legitimate job, then if it has
an exploitable vulnerability, the attacker can only abuse that limited
authority.

<caveats>

Unfortunately, just as processes running on the same account on a
conventional OS can mess with each other, so can frames running as the same
origin. The limits to Solitaire's abuse potential above includes the
authority of other A-origin frames running at the same time as Solitaire.
This makes it difficult to reason about precisely how much these measures
help; but it is still clear that they would often help a great deal
depending on the users habits.

Of course, only a handful of people -- all of whom you and I probably know
-- operate sites as "pure secret token based" with no ambient credentials
whatsoever. Any transitional strategy has to accomodate some kind of login,
where the login page makes a transition from a page with little authority
(itself) to a page holding all of that user's authority at that origin (say,
that user's "home page" at that origin).

In order for all the rest of this hypothetical reduction of XSS
vulnerability to pay off, we need merely run the login page itself at an
origin other than A, in order to protect itself from an XSS on an
application page at A. Only the transitions within A and out of A must be
pure secret token based. The transitions into A can be by other means
separately protected.

If the XSS vulnerability in question is on the user's A home page, then we
haven't gained anything. But there will be some distribution of
vulnerabilities across pages, and most of the site's pages should carry far
less authority.

</caveats>

I am not advocating that people use the above techniques by themselves to
ameliorate their XSS vulnerabilities. Better to fix the XSS problem with
technologies like Caja. But neither do I expect immediate pervasive adoption
of Caja or of pure secret token systems. The point here is simply that this
is a practical scenario, both simpler and more secure than current practice
and independent of JavaScript sanitization, whose security even against
XSSes would be weakened by extending conventional identified-origin access
control into cross-origin requests.

-- 
   Cheers,
   --MarkM