W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 25 Jun 2012 16:09:03 -0400
Message-ID: <4FE8C55F.2090307@mit.edu>
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.

Received on Monday, 25 June 2012 20:09:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:06 UTC