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

The below doesn't appear to be a technical criticism of
Origin-as-CSRF-defense but rather a recommendation for a certain
design pattern for building web applications.  That design pattern
seems useful.  You might consider building a framework a la Rails that
makes it easy for developer to adopt this design pattern.  (Perhaps
that's what the Waterken server is?)

I've included some comments inline.

On Mon, Jun 8, 2009 at 11:05 PM, Mark S. Miller<erights@google.com> wrote:
> 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.

Yes.

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

It's unclear what user habits you have in mind.  In general, relying
on the user to behave a certain way is a recipe for insecurity.

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

I'm not sure this is correct.  Suppose I know a stored XSS attack on
page X of origin A.  The user visits page X.  Now, you agree that I
own page X and all its descendants in the capability lattice.
However, I claim I own all of origin A.  Here's my plan for owning an
arbitrary page Y.

1) The user visits page X.  I now am running script in origin A.  I
call window.open("http://boring.com/", "foobar").

2) The user decides they don't like boring.com and navigate back to A
in that new window.

3) The user visits page Y.

4) I call window.open("javascript:[evil script]", "foobar")

5) The browser notices that X and Y are from the same origin and runs
my evil script in page Y.

6) I own page Y.

I don't see how moving the login page off-domain helps.

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

Which is one reason I see the Origin-as-CSRF-defense as being useful.

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

You haven't actually made this argument.  You've invented some complex
scenario in which if everything is arranged just so, then the
Origin-as-CSRF-defense isn't as robust as another more complex
mechanism.  As I said at the outset, the Origin header is a simple
CSRF defense for simple sites.  If you've got a lot of engineering
horsepower to spend on CSRF defense, you should build the Rolls Royce
of CSRF defenses.  (Actually, in the case you present, you might as
well use *both* the Origin header and secret tokens in case one or the
other screws up in some way.)

Adam

Received on Tuesday, 9 June 2009 07:16:29 UTC