On Thu, Mar 1, 2012 at 9:54 AM, Geoffrey Sneddon <[email protected]> wrote:
> On 26/02/12 09:39, David Bruant wrote: > >> Le 26/02/2012 01:23, Geoffrey Sneddon a écrit : >> >>> I've basically implemented something close to what is attributed to >>> >>> Dave Herman on the wiki in Carakan now, albeit without the context >>> check, though I agree it's a good idea. I wonder if it's >>> web-compatible to disallow cross-context prototype chains (both >>> through __proto__ and Object.create). >>> >> What is asked to be disallowed is only changing the prototype with >> __proto__ in a cross-context manner. >> Creating cross-context chains with Object.create has not been discussed >> I think and should be fine... >> >> ....or not? >> Given an attacker from context A, a defender from context D (I'll use >> these letters to refer to the global object of each context). An >> attacker can create an object like >> ----- >> var maliciousProto = Object.create(D.Object.**prototype); >> // Add whatever own properties to maliciousProto >> >> someObjectInD.__proto__ = maliciousProto >> ----- >> >> I was enthusiastic by Gavin Object.prototype ownership-based solution, >> but it seems that as long as an attacker has the possibility to create >> cross-context objects, an Object.prototype-based solution actually does >> not prevent anything. >> > > I don't think there's much in the way of a security risk here (given that > if you have access to D anyway you can execute arbitrary code within it). Hi Geoffrey, I agree with your conclusion -- the Object.prototype-based solution seems sound -- see my previous reply to David. But I completely disagree with your reasoning. Now that ES5 is deployed, you can lock down D so that you can execute untrusted code in it securely. In fact, this is the *only* form of execution in which modern browsers support confinement of untrusted code. HTML5 unique origin sandboxed iframes are much weaker as a security mechanism -- in this and many other ways. > Even if __proto__ has been deleted you can just create a new object > "someObjectInD" with mailiciousProto through Object.create. > > The only reason to prefer to avoid cross-context prototype chains is one > of elegance: in my view it seems somewhat inelegant, though the more I > think about it the less I can justify that position. > > > The one thing I would prefer, however, would be that the setter is >>> optional (i.e., it is permissible to have __proto__ have just a getter >>> or have both a getter and a setter, but not just a setter). >>> >> I think that it's unrealistic since the web does use the setter as well. >> If the setter was standardized as optional, all implementations would >> implement it anyway. >> > > I was speaking to Jeff Walden a few or two back about this — both of us at > least still live in hope of someday getting rid of the setter. As far as > either of us are aware, there isn't much legacy for the setter, mostly > concentrated within a few libraries, which hopefully we can evangelize it > out of — and then re-evaluate where we are in a few years and see whether > the legacy has decreased, and older versions of the libraries have gone. > Being obliged per spec to implement the setter forever seems undesirable, > if we can manage to get rid of the legacy. > > > -- > Geoffrey Sneddon — Opera Software > <http://gsnedders.com> > <http://opera.com> > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
