- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 7 Jun 2009 12:12:53 -0700
- To: "Mark S. Miller" <erights@google.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>
Hi Mark, Thanks for your feedback. At a high level, you seem concerned about very advanced sites (e.g., ones use object-capability mashups). The Origin-header-as-CSRF-defense is aimed at making CSRF defense easier for simple sites. Just like you need to do complex gymnastics to avoid XSS when running untrusted JavaScript in your security origin, you'll also have to use one of the more complex CSRF defenses, such as secret tokens, in these cases (just as you need to do for all sites today). Detailed comments below.. On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller <erights@google.com> wrote: > I admit that I haven't followed in detail the various origin > proposals (cors, html5, ietf (withdrawn?)). I am glad to see that > people want an origin proposal with good security > properties. However, I fear all the current proposals amplify one of > the browser's worst security hazards -- abuse of ambient authority > creating confused deputy hazards. The current browser same origin > policy already has plenty of these problems > <http://waterken.sourceforge.net/aclsdont/>. For better or worse, that's the security model we've got. Worrying about this for the Origin-header-as-CSRF-defense is a bit like horse is gone (to borrow a cliche). Almost all browser security features have this behavior. For example, cookies, the Origin-header-for-CORS, postMessage, localStorage, window.open, the password database, etc. > To be concrete, pages contain content -- whether mashups, gadgets, or > simple libraries -- whose authorship does not correspond to the > browser's notion of origin. As Crock said in his w2sp keynote > <http://w2spconf.com/2009/presentations/keynote-slides.pdf>, "A mashup > is a self inflicted cross site script." The problem isn't the mixing > of scripts representing different interests. The problem is that all > scripts that execute on a page are implicitly allowed to exercise all > the authority that this browser associates with that page's origin. Getting the security right for mashups that run untrusted script in a trusted security origin is really tricky, as I'm sure you're quite aware. Fortunately, the vast, vast majority of web sites don't have to worry about these issues. These web sites, however, do have to worry about CSRF. The goal of the Origin-header-as-CSRF-defense is to provide low-cost way for sites to mitigate CSRF vulnerabilities. A site that's doing some complicated Caja-style mashup has already bitten the complexity bullet and will need to use a complex CSRF defense. > How do these origin proposals amplify this hazard? The main (only?) > motivation for the origin header is to enable servers to make > allow/deny access decisions on cross-origin requests based on the > presented value of the origin header. This means that a script running > on a page from origin A can now make a cross-origin request to a > server at origin B and exercise the authority that this server > associates with origin A. If some of these origin proposals still > allow the browser to present the credentials (e.g., cookies) that > browser associates with B, then, despite protestations to the > contrary, we have also failed to address existing XSRF dangers. You're assuming that origin A is using a complex Caja-style mashup. We're not after that use case. The Origin-header-as-CSRF-defense doesn't make A or B's job any harder. It just makes life easier in the common case. > Three proposals I've seen in these threads, if combined and extended, > point towards a solution. [Snip long proposal to introduce a XMLHttpRequest3 that always sends an null Origin header.] This proposal is compatible with the Origin-header-as-CSRF-defense. I drafted the requirements to allow for this kind of future innovation. In particular, the user agent is always allowed to send Origin: null if the UA thinks that's a good idea. Adam
Received on Sunday, 7 June 2009 19:13:47 UTC