[+synodinos] 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? > yes, The last comment from Dio (cc'ed) of InfoQ, the organization putting on the conference, says: 21 hours ago by *Dionysios Synodinos* Due to a technical issue (tape corrupted) the last 20' of this presentation where lost. Please accept my apologies on behalf of the InfoQ team. You can find the *full* presentation slides in PDF format here: <http://qconsf.com/dl/qcon-sanfran-2011/slides/MarkS.Miller_RemainingHazardsAndMitigatingPatternsOfSecureMashupsInEcmaScript5.pdf> http://qconsf.com/dl/qcon-sanfran-2011/slides/MarkS.Miller_RemainingHazardsAndMitigatingPatternsOfSecureMashupsInEcmaScript5.pdf I was very disappointed to find this out because the session went on for another 20 minutes or so, with some really great audience interaction. Oh well. > 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). Very good. This is indeed the third attack shown on slide 48 of the pdf linked to above. > 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. > Very good again. This is the defense against the third attack, shown on slide 50. (With the applyLater helper function defined on slide 49). It is shown again on slide 51 using the strawman infix ! sugar. > > > 2) A DoS attack by adding subscribers within a subscriber > > topic.subscribe(function resubscribe(publication){ > topic.subscibe(resubscribe); > }); > > topic.publish('bla'); > No, I consider this attack to be out of scope, as a DoS attack can be trivially mounted anyway by any code in that frame which receives control, simply by going into an infinite loop. (Regarding the browser timeout-abort workaround for infinite loops, these only defend against accidents. There are plenty of other ways for code within a frame to successfully DoS that frame.) [...] > > > 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? As Felix says, you already saw attack #1 at slide 45. Attack #2 is "Aborting the wrong plan" on slide 47. The defense on slides 50 and 51 defends against both attacks #2 and #3. And the code on those slides already incorporates the defense against attack #1. And my concluding slide #52 was a callback to slide #3. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
