Detecting the "type" of a DOM object

[Tom Van Cutsem]

2012/6/25 Allen Wirfs-Brock <allen at wirfs-brock.com>

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

I think you may have misunderstood: in terms of the direct proxy API, the
issue referred to on the old Proxy API page was about the danger of having
|proxy instanceof function| trap as |handler.hasInstance(target,
function)|, thus giving the proxy access to the target (irrelevant in this
context) _and_ the RHS function object, which would be a new way for values
to interact.


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

Your point is that any existing host object _could_ already leak the LHS
object (as indeed the spec allows). I think David's point is that as long
as no platform-provided host object actually _does_ leak the LHS object,
then for all practical purposes |instanceof| currently doesn't leak the LHS
object.

As to my own opinion about this issue: while I agree we don't want |a
instanceof b| to give a access to b, I'm less convinced that the opposite
"leak" is all that problematic. If you're given an "untrusted" function F,
how much trust can you place in the outcome of |obj instanceof F| anyway?
Even with the [[InstanceofHint]] trickery, the outcome of the test remains
untrusted. Granted, an attacker might take you down the wrong branch of an
if-test but still can't get at your |obj|. I guess what I want to say is
that code that needs a high-fidelity branding mechanism is better off using
alternatives (e.g. WeakMap) rather than relying on instanceof.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120625/93d8ce43/attachment.html>