Proposal About Private Symbol
Gary Guo
nbdd0121 at hotmail.com
Sat Dec 20 20:08:09 PST 2014
Technically speaking there is no way to prevent such a attack, since in the debugger everything can be exposed to external environment. Careful check is still needed with private symbols according to my proposal.
```js
var constructor=function(){
'use strict';
var sym=Symbol('private', true);
var identifier=Symbol(undefined, true);
var ret=function(){
if(this===undefined)throw Error('Cannot be called as function');
this[Symbol.for('id')]=identifier;
};
ret.prototype.set=function(){
if(this[Symbol.for('id')]!=identifier)throw Error('Invalid This');
this[sym]=1;
}
return ret.bind(undefined);
}();
```
________________________________
> Date: Sat, 20 Dec 2014 22:48:37 -0500
> Subject: Re: Proposal About Private Symbol
> From: zenparsing at gmail.com
> To: nbdd0121 at hotmail.com
> CC: es-discuss at mozilla.org
>
>>2. They would not invoke any traps on proxies.
>>3. They would not tunnel through proxies to proxy targets.
>>4. Getting a private-symbol-keyed property would not traverse the
> prototype chain of the object (perhaps arguable).
> Unnecessary, as long as symbol doesn't leak to external environment, I
> don't think we need to impose these constraints. Without these
> constraints I did not see any problems there.
>
> You simply cannot allow 2 and 3 and still call them private symbols.
> If you allow 2, then an attacker can discover private symbols by
> creating a proxy for an object which uses them in one of its methods.
> If you allow 3, then private symbols are an unmediated communication
> channel across membranes.
>
More information about the es-discuss
mailing list