__proto__ security

Tom Van Cutsem tomvc.be at gmail.com
Fri Feb 10 03:46:35 PST 2012


I'm also in favor of exposing __proto__ as an accessor on the grounds that
it is least magical. I'm worried that the changes made here to the core
internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and [[Delete]]
will give proxies a hard time to properly emulate this behavior if they
would want to do that. How would a proxy handler be able to access the
internal variable UnderscoreProtoEnabled?

(I currently assume that in any event, aProxy.__proto__ would just trigger
the "get" trap for "__proto__" and that all of this magical behavior does
not apply to proxies, only built-in normal objects.)

Also +1 to Gavin's proposed alternative to the frame-check.


2012/2/10 Gavin Barraclough <barraclough at apple.com>

> On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote:
> I would expect Gavin's approach to ultimately be even worse than mine from
> a semantic analysis perspective. It expose (via
> Object.getOwnPropertyDescriptor)  functions that have the ability to mutate
> any object's [[Prototype]] property and one those functions are exposed
> they can be installed as methods or explicitly called at any time.  I think
> that tame them is likely to have even greater impact than what I have done.
>  Certainly, for the ES5 language level (which is what my current spec.
> addresses) there is no way to talk about frames or the association of one
> of these functions or any other object with a frame.  With my approach
> there is no need to match the proto mutator function's frame with the
> target object's frame, because there is no mutator function.
> Hi Allen,
> I completely agree with you that frame-based checks should not be a part
> of the solution, however they are no more necessary if __proto__ is an
> accessor property then if it is a data descriptor.  The solution I proposed
> was that the [[ProtoSetter]] should hold a private reference to the Object
> Prototype upon which it is initially assigned, and that upon being invoked
> it should walk the this object's prototype chain to see if it any entry
> matches the stored value.  With a check such as this in place (I expect
> there are other ways we could achieve this), it would not be possible to
> apply a given [[ProtoSetter]] to any object other than those upon which it
> would initially have been available to operate via the Object Prototype.
> Finally there is the object literal issue which was not address by the
> original wiki proposal.
> You're right, we do need to expand the proposal to cover this.  This
> doesn't seem too difficult.  If the identifier being assigned to in an
> object literal initialization is "__proto__", then check whether the Object
> Prototype contains a property named "__proto__" whose descriptor has a
> "set" value equal to that Object Prototype's original [[ProtoSetter]]
> function, if so then the assignment sets the newly constructed object's
> prototype, otherwise it defines a own property as usual.
> cheers,
> G.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120210/59a254d4/attachment.html>

More information about the es-discuss mailing list