Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)
Mark S. Miller
erights at google.com
Tue Nov 8 11:46:57 PST 2011
On Tue, Nov 8, 2011 at 11:29 AM, Andreas Rossberg <rossberg at google.com>wrote:
> On 8 November 2011 19:13, Mark S. Miller <erights at google.com> wrote:
> > The reason Proxy.attach may not be fatal is that it only allows
> > to extensible objects. Our hypothesis is that any ES5 object that is
> > interested in defending itself has already made itself non-extensible.
> > is why we must key this off of non-extensibility, rather than
> introducing a
> > new orthogonal bit -- to avoid breaching the defenses of those ES5 era
> > objects that tried to defend themselves.
> I don't think that addresses the issue I was describing. The problem
> is: the object itself can all be frozen, non-extensible,
> non-attachable just fine, but that doesn't achieve much by itself
> anymore because an attacker can still attach to each individual
> method, since they are entirely separate objects!
> So instead of just freezing an object, you _additionally_ would have
> to make all its _individual methods_ non-attachable (by whatever
> means). AFAICS, that affects assumptions of existing ES5 code quite
In general, for an object to be defensive, much of the surface reachable
from it by transitive prototype and reflective property traversal should
usually be frozen, and at least non-extensible. This is possible to express
in ES5 <
but inconvenient and expensive. That's why I have been advocating better
defensive abstractions for ES6: "const functions", "const classes",
"traitsjs" or its syntactic derivatives, etc.
Nevertheless, I see your point. Many defensive ES5 abstractions will be
less defensive than this. If I understand you correctly, your point is
specifically about the [[Call]] and [[Construct]] traps. Perhaps we should
be more conservative here, without necessarily backing away from the whole
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss