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

On Wed, 17 Jun 2009 01:52:36 +0200, Mark S. Miller <erights@google.com> wrote:
> I've now read the relevant portions of <
> http://dev.w3.org/html5/spec/Overview.html#the-iframe-element>. Looks  
> like a
> great start on the right direction! I'm genuinely enthused. Some  
> questions:

FWIW, I may be wrong in which case I hope Ian will correct me.


> The second example says "[...] and the origin sandbox restrictions are
> lifted, allowing the gadget to communicate with its originating  
> server."  I
> don't understand this. Given the cors this document assumes, couldn't the
> gadget do a cross-domain xhr to the originating server anyway?

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

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.)


> * 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.


> * 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.


> 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.


> 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.


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


> 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.


> 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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 17 June 2009 11:30:23 UTC