__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