"Remaining Hazards and Mitigating Patterns of Secure Mashups in ECMAScript 5"

David Bruant bruant.d at gmail.com
Sun Mar 18 05:27:47 PDT 2012


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


More information about the es-discuss mailing list