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

On Wed, 17 Jun 2009 15:22:27 +0200, Mark S. Miller <erights@google.com> wrote:
> On Wed, Jun 17, 2009 at 4:29 AM, Anne van Kesteren <annevk@opera.com>  
> wrote:
>>  * 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.

That will still work, but I don't think that's always enough. E.g. if you embed a Google Maps widget in your page it would be nice if the widget could still obtain user preferences from other visits to Google Maps (like default location) while not being able to spawn popups or navigate the top-level browsing context.


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

Cookies (and HTTP authentication) in a request do not depend on the source but on the destination. So XMLHttpRequest would have to be explicitly told not to include them for one reason or another.


>> [SNIP]
>>
>> 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?

Pretty much. data URLs have a little more freedom due to allowing any media type but are more complicated for authors to use.


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

I think you misunderstand. Invoking postMessage() causes an event to be dispatched that as currently specified _always_ includes the origin from the script that invoked the method. (Currently this is specified in section 8.2.3 of HTML5.)


>> 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 we make it so, that is ;-)


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

Certain servers allow user access purely based on their IP. If such a user visits evil.com that site could do data theft and potentially other harmful things to the site the user is authenticated with through IP-based authentication if cross-origin requests do not require any kind of opt in.


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

I think we want requests that include authentication data as well. It seems you are suggesting HTTP authentication and cookies have no use. Which might be fine, but is a completely different perspective from what we have been operating with here.


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

Received on Wednesday, 17 June 2009 13:39:37 UTC