Lecture series on SES and capability-based security by Mark Miller

Mark S. Miller erights at google.com
Fri Nov 4 18:44:57 PDT 2011

On Fri, Nov 4, 2011 at 10:37 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

>    function Bob(t) {
>       var stolenArray;
>       var hackedPush = function() {
>           stolenArray = this;
>       };
>       t.store("push", hackedPush);
>       t.add(0);
>       console.log(stolenArray);
>    }
>    Bob(makeTable());
> As an aside: This problem would go away if we really did distinguish
> between accessing a property and accessing a collection element. Then the
> former would be done via Object.* methods, while the latter would be done
> via square brackets.

I admit that I haven't followed the previous thread on ".[" and such. Is
there a short summary? I ask because my diagnosis is similar but my
conclusion is reversed. The lesson I take from this is not to use objects
as maps. It you want a map, create a Map() and say map.get(key) and
map.set(key, value) rather than using square brackets.

The remaining case is arrays. My conclusion there is to always say
array[+i] rather than array[i]. If Alice had already been practicing this
as a habit, then her table abstraction would have been naturally robust
against this attack even if Alice never thinks of this specific attack.

Having eliminated both of these uses of unmarked square brackets (lists and
maps), the only remaining justified use of unmarked square bracket indexing
is reflection. If you see an unmarked square bracket that's not doing
reflection, you should probably refactor.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111104/d97bae62/attachment.html>

More information about the es-discuss mailing list