Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)

On Wed, Jun 17, 2009 at 3:35 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 17 Jun 2009, Mark S. Miller wrote:
> > >>
> > >> Does an xhr from a sandboxed unique origin iframe carry any
> > >> credentials in the sense in which we've been using in this thread:
> > >> * HTTP auth info
> > >> * cookies (I think the text implied not, but I'd like to check.)
> > >> * client-side certs
>
> Same-origin XHR will just fail with a sandboxed unique origin iframe.
>
> If you mean cross-origin XHR2,


Yes, I do. What does an XHR2 from a sandboxed unique origin iframe do wrt
HTTP auth info and client side certs?



> then it will work the same as for any other
> cross-origin situation, which I believe means "it depends on the
> credentials flag", but I can't see where that is initialised so I don't
> know what the default is.
>

Anyone?


>
>
> > >> * REFERRER
>
> Changing the origin doesn't affect the referrer (that is, it doesn't
> affect the "document's current address" of any document), so assuming that
> XHR2 uses the 'fetch' definition from HTML5 or has equivalent text that
> invokes the "document's current address" to set Referer (sic), the
> referrer will be included.
>
>
> > >> * identified Origin (clearly not if I understand the spec)
>
> Right, this will be serialised as "null".
>
>
> > >> If it does transmit any of these currently, are there any objections
> > >> to revising the spec so that it doesn't?
>
> Why?
>

So that the containing page can use such a credential removing service to
allow sanitized content within the page to make requests -- either to its
own or to other origins -- while preventing this content from "speaking for"
the containing page or the user.

More generally, XSRF is just a special case of confused deputy. The
fundamental reason for confused deputy confusions lies in the distinction
between ambient authority and designated authority. (See links below.) In
the browser context, the presentation by the browser of additional
information, beyond that explicitly provided by the requestor, which servers
then use to make access control decisions, is the ambient authority causing
XSRFs.

The threads starting at <
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0737.html>
have much more on this.

I also like the links in the "6. JavaScript Security / Preparation" section
at <http://www.w3.org/2001/tag/2009/06/23-agenda#security> of the TAG agenda
for their upcoming meeting. See especially <
http://www.w3.org/2001/tag/doc/resource-protection/20090615> which I think
explains the issues well.

With these revisions to the sandboxed iframe spec, we can avoid the need to
create a similar but different GuestXHR spec. The one spec can serve both
purposes. We can then separately discuss whether this also replaces the need
for the rest of CORS and for identified Origins.

-- 
   Cheers,
   --MarkM