On Sun, Jun 7, 2009 at 12:12 PM, Adam Barth <span dir="ltr"><<a href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Mark,<br>
<br>
Thanks for your feedback. At a high level, you seem concerned about<br>
very advanced sites (e.g., ones use object-capability mashups).</blockquote><div><br>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.<br>
<br>I do wish to take issue with your "very advanced" comment. While Caja-like systems are complex to *implement* on current browsers, they are much simpler to use safely and successfully than is the current incoherent mess of the current so-called "browser security model", about which more below. Anyone *safely* doing anything even moderately ambitious using the current browser security model is much more "advanced" than is safe use of Caja-like systems. <br>
<br>Even with the complexity needed to use and deploy JavaScript sanitizing technology today, between Facebook and Yahoo Application Platform, they are already widely deployed (> 120M users) and deserve to be taken seriously. With the immanent arrival of EcmaScript 5, Caja-like systems will become trivial to build, be safer while accommodating an extended threat model, and will be faster and smaller than is possible today.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The Origin-header-as-CSRF-defense is aimed at making CSRF defense easier<br>
for simple sites. Just like you need to do complex gymnastics to<br>
avoid XSS when running untrusted JavaScript in your security origin,<br>
you'll also have to use one of the more complex CSRF defenses, such as<br>
secret tokens, in these cases (just as you need to do for all sites<br>
today).<br>
</blockquote><div>[...]<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For better or worse, that's the security model we've got. Worrying<br>
about this for the Origin-header-as-CSRF-defense is a bit like horse<br>
is gone (to borrow a cliche). Almost all browser security features<br>
have this behavior. For example, cookies, the Origin-header-for-CORS,<br>
postMessage, localStorage, window.open, the password database, etc.<br>
<div class="im"></div></blockquote><div><br>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.<br>
<br>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. 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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Getting the security right for mashups that run untrusted script in a<br>
</div>
trusted security origin is really tricky, as I'm sure you're quite<br>
aware. Fortunately, the vast, vast majority of web sites don't have<br>
to worry about these issues. These web sites, however, do have to<br>
worry about CSRF. The goal of the Origin-header-as-CSRF-defense is to<br>
provide low-cost way for sites to mitigate CSRF vulnerabilities. A<br>
site that's doing some complicated Caja-style mashup has already<br>
bitten the complexity bullet and will need to use a complex CSRF<br>
defense.<br>
<div class="im"></div></blockquote><div><br>(See above re "complicated".)<br><div class="im"><br>
</div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">You're assuming that origin A is using a complex Caja-style mashup.<br>
We're not after that use case. The Origin-header-as-CSRF-defense<br>
doesn't make A or B's job any harder. It just makes life easier in<br>
the common case.<br></blockquote>
<br>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.<br>
<br>* 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. <br><br>* 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.<br>
<br>
* 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. 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. 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. If servers obey the cors recommendations and instead allow such access without a secret token, then they become open to new attacks. In this case, the use of an identified Origin would be harmful.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Three proposals I've seen in these threads, if combined and extended,<br>
<div class="im">
> point towards a solution.<br>
<br>
</div>[Snip long proposal to introduce a XMLHttpRequest3 that always sends<br>
an null Origin header.]<br>
<br>
This proposal is compatible with the Origin-header-as-CSRF-defense. I<br>
drafted the requirements to allow for this kind of future innovation.<br>
In particular, the user agent is always allowed to send Origin: null<br>
if the UA thinks that's a good idea.<br>
<font color="#888888"></font></blockquote><div><br><br>I am glad you ended on that note. As I mentioned at the beginning of this thread, I was glad to see in your IETF proposal that user agents are allowed to send "Origin: null". I am distressed by the absence of similar language in cors. Worse, what I have not yet seen in any proposal is a way for JavaScript code to say to the browser "please send all these requests with no credentials, and with an 'Origin: null' header."<br>
</div></div><br>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. <br>
<br>Switching metaphors and quoting again your<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">For better or worse, that's the security model we've got.</blockquote>
<div><br>As someone once said, if you find that you've dug yourself into a deep hole, the first thing you should do is stop digging. <br></div><br>-- <br> Cheers,<br> --MarkM<br><br>