__proto__ security

Gavin Barraclough barraclough at apple.com
Sat Jan 28 01:02:01 PST 2012

On Jan 20, 2012, at 4:07 PM, David Bruant wrote:

> * What are all the cases in nowadays browsers where a new
> Object.prototype.__proto__ can be dynamically created? (The only one I
> can think of is same-domain iframe, but I think there exists some weird
> rules for one frame to access another by changing its own domain to a
> subdomain, or something like this)
> * For each case, who has access to the other first? The creater or the
> creature?
> * One difference that is made in the accessor case is that if one party
> runs before the other, then this first one can keep a reference to the
> setter. Does this increase the already existing attack surface?

Hi David,

It seems that the best way to neutralize the thread from new __proto__ instances, would be to simply prohibit __proto__ taken from one iframe to be applied to objects created in another.  I think this should be achievable with the following tweaks to the strawman:

* The [[ProtoSetter]] method holds a private reference [[OwnerObjectPrototype]] to the ObjectPrototype upon which .
* Add a step 2b to the definition of [[ProtoSetter]](Parent), specifying:
	Walk the prototype chain of O, comparing each successive prototype to the stored [[OwnerObjectPrototype]].  If the prototype chain does not contain [[OwnerObjectPrototype]], throw a TypeError.

What do you think? – are there holes this leaves open?


More information about the es-discuss mailing list