Why not private symbols?

Tab Atkins Jr. jackalmage at gmail.com
Fri Aug 2 13:19:08 PDT 2013


On Fri, Aug 2, 2013 at 1:15 PM, Domenic Denicola
<domenic at domenicdenicola.com> wrote:
> From: Brandon Benvie [bbenvie at mozilla.com]
>
>> That would leak the Symbol to the Proxy and then private Symbols wouldn't carry a guarantee of security. That's the only difference between private Symbols and unique Symbols.
>
> Right, I thought about that, but I am still not quite clear on what the attack is here. From an ocap sense, it feels like you're handing off the private symbol to the proxy, which is just like exporting it from your module or passing it to a function. Why should the proxy not have access to something that you gave it?

The issue is that you may not know the proxy is there.  Someone
constructs an object of your class, then wraps it in a proxy and
passes it into one of your methods.  You, assuming it's a real member
of your class, talk at it via private symbols to fiddle with the
internal state.  The proxy intercepts those, and now has access to the
internal object state that it wasn't supposed to have.

This is very different from explicitly handing the private symbols to
something else.

> The attacks I normally consider public symbols vulnerable to are of the form:
>
> ```js
> module "foo" {
>   const public = Symbol();
>
>   export default {
>     [public]: 10
>   };
> }
>
> module "bar" {
>   import foo from "foo";
>   // Nobody gave me access to the `public` symbol, but I can still do:
>   const public = Object.getOwnPropertyKeys(foo)[0];
>   // Now I can modify the exported object:
>   foo[public] = 20;
> }
> ```

Private symbols don't show up in getOwnPropertyKeys(), I believe.
(Otherwise, you're right, there's no concern with leaking them to
proxies, because they'd be auto-leaked to the world by default
anyway.)

~TJ


More information about the es-discuss mailing list