Detecting the "type" of a DOM object

David Bruant bruant.d at
Mon Jun 25 09:27:01 PDT 2012

Le 25/06/2012 17:36, Allen Wirfs-Brock a écrit :
> On Jun 22, 2012, at 11:01 AM, David Bruant wrote:
>>> ...
>> There is a potential security issue. From the wiki [1] (in the case
>> where the instance is a proxy trapping on instanceof): "Security issue:
>> the handler is given a reference to the function object (the right-hand
>> side of the instanceof operator). This gives the handler the ability to
>> generate new instances of that function. "
> I note that the referenced material[1] is part of the original Proxy proposal and not the current direct proxy proposal.  I may be missing something here, but with direct proxies every handler is passed a reference to its target object and hence if the target is a constructable function the handler might generate an instance of it.  Given that, I don't see why an instanceof trap exposes any more than any other trap.
The potential leak could arise when you test instanceof (in the naive 
hasInstance trap case) with something that wasn't created through the 
constructor, like:

     mySecretObject instanceof SomePotentiallyUntrustedConstructor

And I agree with you, the constructor has "full power" over instances it 
generates. The constructor doesn't even need to be a proxy for that.

>> In my opinion, the issue stands if the choice is to have either the LHS
>> or RHS of instanceof to trap on instanceof. The more general issue isn't
>> about generating new instances, but about an object gaining access to
>> another object it didn't have access to before the instanceof
>> evaluation. Both cases result in a capability leak.
>> To be more precise, currently, when you write "a instanceof b", you
>> don't expect either a or b to leak. This property should probably be
>> preserved even with proxies.
> You are probably correct about the expectation, but it doesn't reflect what is actually specified by ES<=5.1.
Does it matter? [[HasInstance]] is a specification internal mechanism. 
There is nothing preventing from re-specifying it (like I suggested in 
my proposal as an example) as long as it keeps backward compatibility. 
The same probably goes for any internal method.
It's actually the last time this can be done, because proxies will 
expose a lot of the internal machinery to user code.

> The normal specified implementations of instanceof or any other polymorphic internal methods don't leak (except in ways fundamental to their normal behavior).  However, there are no guarantees that host object implementations of those methods won't leak.
My understanding of the "let's get rid of host objects" is to enable 
having such guarantees. Is getting rid of host objects a goal? By 
"getting rid of", I mean "making what used to be host objects at worst 
as powerful as proxies".
Specifically, in my proposal, I have redrawn the interface available to 
proxies when it comes to reifying instanceof. If host objects weren't 
more powerful than proxies and my proposal (or any equivalent) were to 
be accepted, then user code would be guaranteed that "host objects" 
won't leak things they're not supposed to.

> Similarly, any value that is reified for use by a Proxy handler could be leaked by the handler. Once such values are presented to externally provided code I don't see how you have any assurance that such code won't pass those values on in ways that you didn't anticipate.
With my proposal, you can check instanceof with an arbitrary untrusted 
constructor and your objects won't leak (I built it for that purpose).
Assuming my proposal is in, could you write a malicious constructor C 
that acquires a reference to an object o with only the line 'o 
instanceof C' and no other interaction between o and C? I'm convinced 
it's not possible, but maybe I'm wrong. This exercice will either point 
to a defect in my proposal or help understanding it better, both being a 
step forward :-)


More information about the es-discuss mailing list