- 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>
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.) Regards, Maciej
Received on Monday, 29 September 2008 11:18:46 UTC