domenic at domenicdenicola.com (2013-08-29T19:15:32.922Z)
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller <erights at google.com> wrote:
> This is an example of what I am worried about. Another is
>
> Object.create(p, {value: Promise}).Promise(....)
>
> where p is a promise.
I'm not quite sure what this is supposed to do, because it's invalid
Object.create. (Or rather, it creates a property named "value" with
default descriptors, which I'm sure isn't intended.)
> Perhaps it would help if, when we start to think "people can fool you
> with..." it would help to substitute "an attacker can fool you with...".
What exactly is the attack scenario being envisioned here, though?
Okay, you can call a function and supply your own `this` value. And?
You can always do this, before or after construction. I don't think
this lets you fool anything, because you, the attacker, have to run
your own code to make it happen. You can't somehow trick the defender
into creating a tricky not-quite-authentic Promise, unless you've
tricked them into using eval() or something. If the attacker is
getting to run code of its choosing, you've already lost.
Am I missing some obvious attack?
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller <erights at google.com> wrote: > On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr. <jackalmage at gmail.com> > wrote: >> >> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller <erights at google.com> >> wrote: >>> On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com> >>> wrote: >>>> But I like just Promise(), sans "new". >>> >>> Good. I like it too, and Allen's latest draft class semantics enables >>> the >>> definition of classes that can do this reliably. But is there any way to >>> reliably polyfill this in ES5? It's not clear. For the std promise API, >>> given the urgency with which people want to use it *now*, I think this >>> polyfillability is important. >> >> Yes, why wouldn't it be? The test for promise-ness can be done today, >> without special browser privilege, and distinguishing between >> `Promise(foo)` and `new Promise(foo)` is a trivial matter of testing >> the type of `this` inside the function. (If it's instanceof Promise, >> you were called with new. Otherwise, you weren't. This isn't 100%, >> as people can fool you with Promise.call(), but that's not something >> you need to actually worry about, I think.) > > > This is an example of what I am worried about. Another is > > Object.create(p, {value: Promise}).Promise(....) > > where p is a promise. I'm not quite sure what this is supposed to do, because it's invalid Object.create. (Or rather, it creates a property named "value" with default descriptors, which I'm sure isn't intended.) > Perhaps it would help if, when we start to think "people can fool you > with..." it would help to substitute "an attacker can fool you with...". What exactly is the attack scenario being envisioned here, though? Okay, you can call a function and supply your own `this` value. And? You can always do this, before or after construction. I don't think this lets you fool anything, because you, the attacker, have to run your own code to make it happen. You can't somehow trick the defender into creating a tricky not-quite-authentic Promise, unless you've tricked them into using eval() or something. If the attacker is getting to run code of its choosing, you've already lost. Am I missing some obvious attack? ~TJ