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

On Sun, Jun 7, 2009 at 2:53 PM, Mark S. Miller <erights@google.com> wrote:
> While I clearly am concerned about object-capability mashups, from your
> response, and from some private responses I've received, I have clearly
> created some confusion by leading with this example. The point I am making
> does not depend on the existence of any JavaScript sanitizing technology,
> Caja-like or otherwise. In this first response to your message, after the
> following two paragraphs, I will leave aside any JavaScript sanitizing
> technology.

Ok.  For the sake of this discussion, let's ignore JavaScript
sanitization technology.

[Snip two paragraphs about JavaScript sanitization technology]

> Currently, prior to the Origin header, as you say, sites use secret tokens
> for CSRF defenses. The presentation of secret tokens as authorizing
> information is a good practice that we should encourage. It is the explicit
> inclusion of authorizing information directly in the payload of the message.
> This is a designated authority pattern that leads away from confused deputy
> hazards. The increasing prevalence of this pattern -- driven by necessity
> since "the security model we've got" failed to provide security -- means
> there are still some horses remaining in the barn.

Regardless of the aesthetics of the secret token defense, the fact
remains that it's error-prone.  In our paper, we found lots of people
screwing up secret tokens.  For example, a number of sites and CSRF
library inadvertantly leaks the secret tokens to untrusted web sites,
opening themselves up to CSRF.  In addition, all of the sites we
examined didn't correctly protect their login form because the correct
use of secret tokens is bound up in session management.

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?

> Instead, your rationale for the Origin header would have sites use
> identified Origins *instead* of secret tokens to make access control
> decisions. This is quite explicit in the cors recommendations for server
> behavior.

Realistically, I expect the Origin header to be used by web
application firewalls to augment a site's existing (and possibly
buggy) CSRF defenses.  In the long term (~5-10 years?), sites might be
able to switch over entirely to using the Origin header, but that will
have to wait for non-supporting browsers to fade away.

> Ok, let's worry here only about XSRFs on websites that use no JavaScript
> sanitizing technology. I have privately heard comments along the lines of
> "Even without Origin, XSSs already enable XSRFs, so how does the
> introduction of Origin enable any new attacks?" It sounds like you are
> posing a similar question.

I also believe this to be true.

> * If servers don't pay any attention to the Origin header and continue to
> rely on secret tokens, then the Origin header does not enable new attacks.
> But in this case Origin would be useless.

Fair enough.

> * If servers change from requiring secret tokens to requiring secret tokens
> *and* appropriate Origin headers, then this is strictly less permissive and
> so does not enable new attacks. But this more restrictive behavior is also
> too restrictive; it would reject some requests that should be allowed. In
> this case, Origin would be worse than useless.

Why do you assume the more restrictive behavior would be too
restrictive?  It seems entirely possible (and actually occurs
frequently) that sites have CSRF vulnerabilities.  If the site uses a
web application firewall that also filters based on the Origin header,
we might well prevent the vulnerability for users of supporting user
agents.

Even if the site doesn't use filter based on the Origin header in all
cases, it's very easy for the site operator (or their security
consultant) to push a web application firewall rule to block the CSRF
while they wait for their developers to patch the code.  Companies
such as WhiteHat security have shown that this model can be very
effective for XSS.  The Origin header lets them apply this workflow to
CSRF as well.

> * If a server in origin B operates according to the cors recommendation and
> allows some access based *only* on the presentation of an origin it "trusts"
> say "Origin: A", then a successful XSS on a page at origin A escalates into
> an XSRF against the server at B. By contrast, if the server at B required a
> secret token, as it must now, then A has some protection against such
> escalation.

This protection is quite weak.

> The XSS attacker, in order to gain more access to B than it
> could have from a page from its own origin, must use its ability to run "as
> A" to obtain the secret token it needs to present to the server at B.

This seems quite easy for an XSS attacker.  In most cases, this
requires only an XMLHttpRequest back to site A.

> If servers at A don't freely hand out such tokens in response to guessable GET
> requests, then the secret token prevents XSS-at-A-attacker's XSRF against B
> from abusing the authority that B associates with A.

I don't see what GET has to do with it.  In any case, the XSS attacker
can always enter the site at the home page (e.g., http://example.com/)
and follow whatever obscure links exist until it reaches the page that
contains the token.  Once the attacker has XSSed site A, the browser
doesn't stop it from acting as site A.  The absence or presence of the
Origin-header-as-CSRF-defense doesn't change this.

> I do like the idea of staging the roll out of features. However, I am
> confused by your sense of the order in which these "innovation" should be
> rolled out. If we roll out "Origin: null" first, then we do not encourage
> websites to stop using secret tokens to protect against XSRF. We do not
> entrench any dangerous habits that would make better security features
> harder to roll out later. With the staging you recommend, we would kill the
> few horses remaining in that barn before we take the steps that could have
> protected them.

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.

Adam

Received on Sunday, 7 June 2009 22:25:21 UTC