#1 was one of the attacks. the other is a consumer can throw an exception and prevent further delivery of publications, which is also fixed by using setTimeout(..., 0);
On Sun, Mar 18, 2012 at 5:27 AM, David Bruant <[email protected]> wrote: > Le 18/03/2012 02:06, Mark S. Miller a écrit : > > http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5 > > > > Has some new material relevant to issue we discuss on this list. Enjoy! > The end of the talk is missing, isn't it? > What are the 2 other attacks? > > I'd try to guess: > 1) Assuming Bob subscribes before Carol: > // in Bob > topic.subscribe(function republish(publication){ > if(publication === "pub") > topic.publish("other publication"); > }); > > topic.publish("pub"); > > Since the call to publish is synchronous, Carol see the "other > publication" before "pub" while it should be the other way around > (according to Alice's intention regarding delivery order). This can > probably be solved with a publication queue or redefining publish as : > > function publish(publication){ > setTimeout(prevousPublish.bind(undefined, publication), 0); > } > > Making the call occur in a later turn guarantees that it happens after > the current turn. Event loop takes care of run-to-completion and turn > ordering. > > If Carol has all her subscribers before Bob's, I don't see how Bob can > attack on this front. > > > 2) A DoS attack by adding subscribers within a subscriber > > topic.subscribe(function resubscribe(publication){ > topic.subscibe(resubscribe); > }); > > topic.publish('bla'); > > Subscribers are added infinitely and the loop never ends. > In this attack, if 2 messages are publish, only one will be delivered to > Carol. > I think the defense can be a queue or a delayed subscription: > > topic.subscribe(function (subscriber){ > setTimeout(Array.prototype.push.bind(subscribers, subscriber), 0); > }); > > > 3) There were only 2 attacks left and this is more ambiguous, but > assuming the publication is mutable, any subscriber can alter it. > A complicated defense is to copy the publication and pass a copy to each > subscriber. An easier defense is to pass immutable publications. > > In a WebIDL-conformant platform, this could be easily achieved by > removing all setters of all event-related properties (they are all as > accessor on *Event.prototype objects). > > Have I found the 2 remaining attacks? > > David > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
