__proto__ security
Brendan Eich
brendan at mozilla.org
Mon Feb 13 09:30:46 PST 2012
David Bruant wrote:
> Le 12/02/2012 23:47, Brendan Eich a écrit :
>> The concern (no trolling here) is at least about attack surface. If
>> there's no setter that can be extracted, there's no need for the
>> "frame check" (however phrased). Adding that check adds more
>> machinery to get wrong or have interact in unexpected ways with other
>> moving parts.
> I'm not sure what you've described is directly a concern of attack
> surface.
No, there is new attack surface (API in the language) compared to *not*
reflecting __proto__ as an accessor at all.
> I think it's rather a concern of "potential bugs surface"
Yes, that goes with attack surface unless it's redundant API to no new
internals. But the frame check requires new internal implementation work.
> (which can indirectly lead to security issues) and I agree that it's a
> valid concern. However, the version where the check is based on the
> Object.prototype identity sounds it could be written quite safely in a
> couple of lines of JS, no ?
Let's stop making a trivial matter of something that isn't fully
attacked yet. __proto__ as pseudo-data property has been around for ~13
years. An accessor variant, days at most. My gut is still unhappy!
/be
More information about the es-discuss
mailing list