'Avoid "this". Use closures rather than prototypes'
Probably the public was stunned by that one... (technical problems too,
could not hear the video, just saw the slides)
Technically for the purpose of your presentation, it is correct, but I
am coming back again to real life, you are using strict mode and other
means (such as questionnable setTimeout(xxx,0)) to secure Bob.
Then what is the use of Bob if he can not do anything outside of himself ?
A much more trivial security leak could be that the calling context does
somewhere unexpectedly (or not) something like counter.x.y.z=window (Ex
: like passing a node to Bob since it seems that Bob has to do some
stuff with the dom to be usefull)
It's the same issue as multiple globals (if the concept of globals still
exist in the future) I believe : how to separate completely several
contexts while using objects between each others ? Looks very difficult
I might be wrong, but on what today's examples the demonstration here
could apply without Bob being useless or just returning something like a
mathematical calculation or such not touching anything in the page ?
Le 18/03/2012 19:25, Mark S. Miller a écrit :
[+synodinos]
On Sun, Mar 18, 2012 at 5:27 AM, David Bruant <[email protected]
<mailto:[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
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
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
