Detecting the "type" of a DOM object

Allen Wirfs-Brock allen at
Mon Jun 25 08:36:22 PDT 2012

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.

> 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.   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.  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.

> ...
> David
> [1]

More information about the es-discuss mailing list