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.
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=699945
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
