W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: Question about origin serialization

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 29 Sep 2008 04:18:03 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: Adam Barth <w3c@adambarth.com>, HTML WG <public-html@w3.org>
Message-id: <E82E7E1F-FF10-4E43-BA40-3F43239F6266@apple.com>

On Sep 28, 2008, at 7:48 PM, Boris Zbarsky wrote:

> Adam Barth wrote:
>> What are the all the different string forms?  The two I'm aware of  
>> are:
>> 1) postMessage's origin property
>> 2) XHR's Origin header
> You're assuming no one else will make use of these serialization  
> rules?
>> Browser implementations won't be able to replace same-origin checks
>> with comparing these strings because of document.domain
> document.domain just comes down to modifying which origins you  
> compare, for what it's worth.

In WebKit at least, that's not the case. If one site has an origin of <http://example.com/ 
 > and another has an origin of <http://subdomain.example.com/>, and  
the latter sets document.domain to example.com, then no access will be  
allowed either way. This would be the case even if both sites  
originally had an origin of <http://example.com/>, but only one  
explicitly set document.domain to example.com. I believe this behavior  
matches Firefox and IE, at least it did at the time we changed to it,  
in December, 2007, and without this restriction there are possible  
security holes.

Thus, we track whether document.domain has been set explicitly as an  
additional flag in our representation of a security origin. (I can  
imagine a different way of implementing it where you have up to two  
origins defined per document and an extra flag to decide which to use  
or something like that, but this in effect also amounts to an  
additional flag that must be checked for same-origin checks.)

Received on Monday, 29 September 2008 11:18:46 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC