On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian <[email protected]> wrote:
> On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller <[email protected]> > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
