- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 25 Jun 2012 19:57:33 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- cc: Bobby Holley <bobbyholley@gmail.com>, public-script-coord@w3.org, w3c@adambarth.com, Johnny Stenback <jst@mozilla.com>, Blake Kaplan <mrbkap@mozilla.com>, Daniel Veditz <dveditz@mozilla.com>
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