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). 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
