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 22:16:20 -0400
Message-ID: <4FE91B74.9080308@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 10:08 PM, Ian Hickson wrote:
> So is taking references to nodes on other sensitive pages before changing
> your security context. :-)

It doesn't even have to be nodes.  Taking a reference to pretty much any 
object that's not the window or document is bad...

And again, the point is to reduce attack surface, not eliminate all 
possible attacks.  If you use eval, you just lose.  ;)

> I wasn't really arguing anything more specific than "we don't value
> document.domain", but if I had to argue something, it would likely be that
> it's not that difficult to not screw this up

I suspect it actually is, because most web developers don't realize just 
how limited the same-origin policy is.

> I don't fundamentally object to adding these requirements, if everyone
> wants to implement them. After all, I'm going to spec whatever the
> browsers do, at the end of the day. But given that these problems only
> occur when you use document.domain, and given that document.domain is a
> security disaster waiting to happen even if we do this, I really don't see
> much point. I'd much rather have document.domain throw a big red warning
> in the console and advocate for its demise.

OK.  Note that in this case I suspect we won't get real interop here, 
because everyone will just implement whatever is easiest for them, which 
happen to be different things...

Received on Tuesday, 26 June 2012 02:16:56 UTC

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