Re: Proposal: Security checks after same-origin revocation with document.domain

On Mon, 25 Jun 2012, Boris Zbarsky wrote:
> On 6/22/12 7:07 PM, Ian Hickson wrote:
> > There's lots of other ways to screw it up, e.g. anything on 
> > foo.example.com that reflects HTML back, even if it checks the origin 
> > of the submitter, would end up letting B run code in A's origin, 
> > letting C do whatever it wants with B
> 
> I don't follow this.

C puts code into B that causes the server to reflect markup of C's 
choosing into an iframe using A's origin (B's original origin, the origin 
used in the Origin: header that B would send when aking the request to the 
server). C thus gets control over A.


> > Similarly, anything on any other port on any other subdomain of 
> > example.com can now access A and B.
>
> No, A and C.  Can't access B.

Right. D can access A and C.


> > In general, authors should IMHO assume that if they've set 
> > document.domain to let another origin's pages access them, they've 
> > given access to the entire origin.
> 
> They don't assume that right now, and if it actually worked that way 
> some things would be pretty broken.

According to you in [1], WebKit and IE _do_ work this way.

http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0120.html


> > If that's not acceptable, then they shouldn't use document.domain, but 
> > should instead use one of the more secure mechanisms like 
> > postMessage().
> 
> That doesn't help with existing content.

Existing content is already vulnerable in a majority of deployed browsers, 
if WebKit and IE both do this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 25 June 2012 19:58:01 UTC