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

On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren <annevk@opera.com> wrote:

>
> HTML5 does not assume CORS at this point I believe. Having said that, the
> "sandboxed origin browsing context flag" does more. It forces the content of
> the <iframe> into a unique origin. A number of features are disabled because
> of this:
>
>  * storage
>  * same-origin communication channels
>  * document.cookie
>  * communicating with the document that hosts the <iframe> if they're
> same-origin
>

What about communication using postMessage? As long as the iframe can
communicate with its containing page using postMessage, denying the rest of
these makes perfect sense, since the containing page can provide
corresponding attenuated services based on its own access to these features.



>
> And maybe more.
>
>
> > 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.)
>
> I don't think these are impacted though XMLHttpRequest cannot be used to
> read or set cookies. (They will still be included in the request as
> currently drafted.)
>

Is there no way to make the unique origin sandboxed iframe cookieless? I
suppose, if not, the containing page could create a fresh unique origin
sandboxed iframe per request, but seems rather heavy. Would that
successfully render the resulting network messages cookieless?


>
>
> > * client-side certs
>
> I don't have sufficient knowledge about these to answer :/
>
>
> > * REFERRER
>
> I think Referer is still included. This may have been an oversight.
>
>
> > * identified Origin (clearly not if I understand the spec)
>
> Unless same-origin is set the origin is a unique identifier. That equals
> the string "null" in requests.
>

Good. Yes, I was asking only about unique-origin sandboxed iframes.


>
>
> > * Anything else I forgot?
>
> I don't think so.
>
>
> > If it does transmit any of these currently, are there any objections to
> > revising the spec so that it doesn't?
>
> Not necessarily. I'd like to know what Ian thinks about this.
>

Wonderful! Ian?


>
>
> > What happens if a data: URI appears as the value of the src attribute?
> > Would this allow the containing page to construct and provide the source
> > directly? Or is this what the document="..." you mention above is for?
>
> The document="" or doc="" idea is to have something simpler than data URLs.
> Basically all you'd have to escape is the double or single quotes used
> around the attribute value and inside could be a complete HTML document.
> data URLs accomplish the same but are tricker with respect to escaping
> rules.
>

Good. So syntax aside, would document="..." and src="data:..." to have
identical semantics?


> How does a sandboxed, unique origin iframe communicate with its
> > containing page? My guess is postMessage, which is necessarily
> asynchronous.
> > However, the useful functionality of the GuestXHR we've been discussing
> would be
> > async as well. (Unless html5 has separate provisions to make sync xhr
> > practical, which would be surprising.)
>
> If you spawn worker threads as detailed in
>
>  http://dev.w3.org/html5/workers/
>
> synchronous XMLHttpRequest is somewhat usable again. Though not ideal if
> you also care about things such as progress events etc.
>

Interesting. But I think we can still leave sync xhr aside for purposes of
the present discussion.


>
>
> > So async GuestXHR would play well
> > with async postMessage as follows:
> >
> > Given the above elements including the removal of all credentials and the
> > acceptance of either document="..." (if I have that right) or
> > src="data:...", then it seems we may be able to build the GuestXHR we've
> > been talking about as an object in the containing page that uses
> > postMessage
> > to relay requests to a sandboxed unique origin iframe acting as a
> > credential removal laundry. Is this analysis right? What am I missing? In
> what ways
> > would these not be equivalent?
>
> postMessage reveals the origin of the containing page.


to the contained sandboxed iframe. But it can of course choose not to
include this info, so it can still act as a credential laundry for network
message.


> On the other hand, if a sandboxed <iframe> restricts XMLHttpRequest in
> various ways XMLHttpRequest is GuestXMLHttpRequest in a sense unless I'm
> missing something.
>

Excellent!


>
>
> > If the above speculations are on the right track, it could be the basis
> > for something much simpler than cors for enabling cross origin xhr
> requests:
> > Only allow cross origin xhrs from browsing contexts that have the
> > "sandboxed origin browsing context flag" set. These xhrs are
> credential-free and not
> > associated with any other origin, and so can safely go cross-origin. For
> > any browsing context without this flag set, its xhr is restricted by the
> > conventional old same-origin policy. If it want to issue a cross origin
> > request, it can use a sandboxed unique origin iframe to launder out any
> > credential confusion.
>
> I followed you so far, but I don't think we want this :-) Besides that this
> causes issues for sites based on IP-authentication it seems that having
> credentialed XMLHttpRequest is a useful thing to have.
>

I don't understand. Could you expand on the IP-authentication issue? Thanks.

Since you say "Besides" above, are there other reasons we don't want this?


>
>
> > The recommended server behavior would then be to allow or deny an
> > "Origin: null" request based only on authorization information explicitly
> placed
> > into the payload, avoiding confused deputy confusions.
> >
> > All redirect-path origin accumulation problems disappear as unnecessary,
> > as would server-side origin-based ACLs.
> >
> > Thanks for your patience and my apologies for taking so long for
> > following up on your question.
>
> It is certainly an interesting thought, but I don't think we can out of
> server acknowledgment of cross-origin requests in one way or another.
> Intranets outside the typical IP-range. Sites using IP-based authentication.
>

I'm not getting this yet. Could you please clarify? Thanks.


-- 
   Cheers,
   --MarkM