On __proto__ as a magical data property

David Bruant bruant.d at gmail.com
Wed Jul 18 00:59:37 PDT 2012

Le 18/07/2012 06:32, Jeff Walden a écrit :
> On 07/17/2012 11:37 AM, Brendan Eich wrote:
>> That's nice but it doesn't address the argument that ECMA-262, not a certain implementation, should not expose a usable setter at all (never mind wrapped and monitored).
>> You'd be on stronger ground if you poisoned the reflection API so the setter could not be extracted.
> I can buy the argument the setter shouldn't be exposed, more or less.  I don't think it presents intrinsic *danger* except in an ocap-y sense, but maybe I'm missing some concrete example.
If the setter had the same restriction than the data property, there is 
no more danger (besides being able to use the setter after a "delete 
Object.prototype.__proto__", but that's not an additional danger).

Im my humble opinion, making Object.prototype.__proto__ configurable 
(and actually deletable) [1] should be a much highier priority than 
choosing from data to accessor property.
As long as Object.prototype.__proto__ is not deletable, a data or 
accessor property does not matter from a security perspective, it's 
equally terrible.
 From the security perspective, it all boils down to whoever runs first. 
If the attacker runs first, it makes Object.prototype.__proto__ 
non-configurable and the defender is likely screwed. If the defender 
runs first, it can "delete Object.prototype.__proto__" and the attacker 
cannot use __proto__ in a nocive manner any longer.
If Object.prototype.__proto__ is effectively deletable, data or 
accessor, the difference is that if you run first and __proto__ is an 
accessor, you can decide to extract the setter and use it for your own 
good if you have legitimate use cases. Never sharing this capability 
will keep you safe.
Still, previous discussion led to the conclusion that "class extension" 
(with the new class syntax) is likely to allow the legitimate use cases 
without the need for a __proto__ setter, making the choice of data or 
accessor an aesthetics choice. If you still disagree on that point, 
please provide examples.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=699945

More information about the es-discuss mailing list