Mark S. Miller (2015-04-29T17:37:41.000Z)
On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller <erights at google.com>
> wrote:
>
>> The invariant I am interested in:
>>
>> In a realm where we (the trusted defender who runs first) make Promise
>> defensive as follows
>>
>> * Freeze everything primordial, as SES does
>>
>> * Make a DefensivePromise subclass of Promise that differs minimally,
>> hopefully only by ensuring that its instances are frozen.
>>
>> * "Promise = DefensivePromise;" do "Promise" below refers to
>> DefensivePromise
>>
>> * Freezing whitelisted global properties, as SES currently does for ES5
>> globals, but for ES6 including "Promise"
>>
>>
>> then it must be the case that
>>
>>     Promise.resolve(anything).then(anycallback)
>>
>> for an anything provided by a potential attacker, when executed in the
>> middle of a turn does not call callback during that turn. If it calls
>> anycallback at all, it calls it back *as* a later turn, i.e., in a later
>> turn starting from an empty stack.
>>
>
> How about:
> ```
> var goodPromises = new WeakSet();
> class DefensivePromise {
>   constructor(x) {
>     super(x);
>     Object.freeze(x);
>     // check this.constructor here if you are paranoid.
>     goodPromises.add(this);
>   }
>   resolve(x) {
>     if (goodPromises.has(x)) {
>       return super.resolve(x);
>     }
>     return new DefensivePromise(function(r){r(x);});
>   }
> }
> ```
> Doesn't seem like this needs special support in the Promise spec.
>
> Note that the `goodPromises` set won't be fooled by passing in
> `DefensivePromise` as `new.target` to `Promise` without actually running
> the `DefensivePromise` constructor.
>   --scott
>

Isn't this still vulnerable to the Promise.resolve attack? IIUC, this
attack enables the attacker to cause this.constructor to lie, so how would
checking it help?



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150429/2d61855d/attachment-0001.html>
d at domenic.me (2015-05-11T16:44:06.640Z)
On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian <ecmascript at cscott.net> wrote:

> How about:

Isn't this still vulnerable to the Promise.resolve attack? IIUC, this
attack enables the attacker to cause this.constructor to lie, so how would
checking it help?