- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 25 Jun 2012 16:09:03 -0400
- To: Ian Hickson <ian@hixie.ch>
- 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 6/25/12 3:57 PM, Ian Hickson wrote: > 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. Hmm. It can't actually access the DOM of A, as far as I can tell. It can obviously run script with the relevant server's principal, of course. >> 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 No, they do security checks at Window boundaries. You're saying that authors should assume those security checks are not there. But they are, precisely to provide _some_ protection. But to actually take advantage of that protection you have to be Really Careful right now. I'm proposing that we allow authors to be Slightly Less Careful without getting screwed, but teach them to be Really Careful (as in, make sure they drop all non-Window-level references) anyway. Which they're have to be while there are UAs implementing the old security model on the market. It's just when they inevitebly screw up being Really Careful they're not automatically vulnerable. > Existing content is already vulnerable in a majority of deployed browsers, I'm proposing we reduce the vulnerability exposure. > if WebKit and IE both do this. And I'm not sure we're talking about the same "this" here. -Boris
Received on Monday, 25 June 2012 20:09:37 UTC