On Wed, Jun 24, 2009 at 1:37 PM, Jonas Sicking<jo...@sicking.cc> wrote: > On Wed, Jun 24, 2009 at 12:52 PM, Tyler Close<tyler.cl...@gmail.com> wrote: >> Hi Jonas, >> >> I'm just asking what Origin header behavior will be shipped in Firefox >> 3.5. You've said redirects of preflighted requests aren't supported, >> so I'm wondering about the non-preflighted requests. > > It will have the Origin header of the original request. We're > considering blocking the request entirely for now though.
Meaning the POST request is delivered to Site A, with an Origin header also identifying Site A, but with a Request-URI chosen by Site B. So Site B can cause the POST request to be sent to any resource on Site A and be processed under Site A's authority. I recommend against shipping that algorithm. Note that this scenario is just a special case of a more general problem with the Origin proposal. Whenever a page issues a request that includes data provided by a third site, that page is applying its own authority to identifiers provided by the third site. This is the essence of a CSRF attack (Confused Deputy). For example, if a page from Site A does a GET to Site B and then includes a received identifier in a subsequent POST to a site other than Site B, Site A is vulnerable to a Confused Deputy attack by Site B. Since the whole point of cross-origin requests is to enable this kind of passing of information between sites, the Origin proposal is poorly suited for access-control in these scenarios. Again, see my paper "ACLs don't" <http://waterken.sf.net/aclsdont/> for an in-depth explanation of why ACL model solutions, such as Origin, can't solve this problem. The section on stack introspection is especially relevant, as Origin is a degenerate form of stack introspection. >> Another question, since Firefox doesn't support redirects of >> preflighted requests, what does it do when it encounters a redirect? > > It aborts and denies the original request. For XHR that means raising > an error event. It's worth wondering whether web pages will come to rely on these requests being aborted and so be vulnerable should a future release not abort the requests. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
