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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5

Has some new material relevant to issue we discuss on this list. Enjoy!

--
    Cheers,
    --MarkM


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

David Bruant-5
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Felix-54
#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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
In reply to this post by David Bruant-5
[+synodinos]

On Sun, Mar 18, 2012 at 5:27 AM, David Bruant <[hidden email]> 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.


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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Aymeric Vitte
'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 <[hidden email]> 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.


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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte <[hidden email]> wrote:
'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)

Not really. I expected more resistance than I got. During the 20 minutes of lively Q&A, this came up again. I clarified then something I should have said earlier in the talk. The objects that need to be defensive are those that might be exposed across a trust boundary, such as the counter in the first example. For objects purely inside one trust domain, given that we really are confident they cannot escape, they do not need to be defensive since their clients are all presumably intimately cooperative.


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.

Sorry, but we're using these techniques in real life. And what's questionable about setTimeout? (or better, <http://dbaron.org/log/20100309-faster-timeouts>)


Then what is the use of Bob if he can not do anything outside of himself ?

Please do make an effort to surmount whatever technical difficulties you encountered, so that you can listen to the audio of the presentation. The slides were not constructed to be self explanatory, and the talk was clear on this point.

 

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)

If Alice does not trust Bob, Alice should generally never give Bob direct unmediated access to one of her dom nodes. Instead, she gives him access to a virtual dom tree that wraps the real dom tree, allowing Bob to manipulate a subtree of Alice's dom tree. We constructed the Domado library <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/domado.js> for exactly this purpose.

The difficultly of emulating the dom faithfully in JS was also the original impetus for the proxy work. The Domado library above does not rely on proxies, as they are not yet as available as ES5.
 

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 ?

I'm sorry, I didn't understand these last two paragraphs. Could you clarify?

You might also want to try some of the scenarios you have in mind at <https://caja.appspot.com/>.


--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Aymeric Vitte
Thanks for your answer, I am myself involved since some time in the DOM and gadgets/widgets's interaction topic.

I will hear the presentation, right now I have a (stupid) problem of non working headphones.

Bob and Alice are ok, but sometimes a good real example can help (last paragraph).

setTimeout(xxx, 0 or 1 or 2 or 500) could be questionable because this is supposed to be fordidden (or not good code...), but surprisingly all major sites do use it, myself too (https://github.com/Ayms/node-dom), regarding http://dbaron.org/log/20100309-faster-timeouts : web workers or postmessage --> bof, I used both in the past for other purposes, prefer setTimeout here

Then if I understand correctly a short summary could be that Caja does help for example iGoogle to move gadgets outside of iframes then they potentially could hurt things but Caja does prevent it and allow them to interact between each others safely (using ES5 improvements)

OK but not everybody is coding safely like Google (even if iGoogle code is very surprising...), then it's difficult to estimate the overall benefit and usuability.
 

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


It's not exactly the same case in fact, except if each gadget becomes an entity with its global object derived from itself (but not an iframe)

For proxies, I am not expert, what does it bring to emulate the dom faithfully ?

Le 20/03/2012 06:27, Mark S. Miller a écrit :
On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte <[hidden email]> wrote:
'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)

Not really. I expected more resistance than I got. During the 20 minutes of lively Q&A, this came up again. I clarified then something I should have said earlier in the talk. The objects that need to be defensive are those that might be exposed across a trust boundary, such as the counter in the first example. For objects purely inside one trust domain, given that we really are confident they cannot escape, they do not need to be defensive since their clients are all presumably intimately cooperative.


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.

Sorry, but we're using these techniques in real life. And what's questionable about setTimeout? (or better, <http://dbaron.org/log/20100309-faster-timeouts>)


Then what is the use of Bob if he can not do anything outside of himself ?

Please do make an effort to surmount whatever technical difficulties you encountered, so that you can listen to the audio of the presentation. The slides were not constructed to be self explanatory, and the talk was clear on this point.

 

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)

If Alice does not trust Bob, Alice should generally never give Bob direct unmediated access to one of her dom nodes. Instead, she gives him access to a virtual dom tree that wraps the real dom tree, allowing Bob to manipulate a subtree of Alice's dom tree. We constructed the Domado library <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/domado.js> for exactly this purpose.

The difficultly of emulating the dom faithfully in JS was also the original impetus for the proxy work. The Domado library above does not rely on proxies, as they are not yet as available as ES5.
 

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 ?

I'm sorry, I didn't understand these last two paragraphs. Could you clarify?

You might also want to try some of the scenarios you have in mind at <https://caja.appspot.com/>.


--
    Cheers,
    --MarkM

-- 
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Aymeric Vitte
In reply to this post by Mark S. Miller-2
Finally I could hear the talk (++ "too bad that the end is missing")

Then I took a look mainly at domado.js, startSES.js, repairES5.js

Quite clever, but quite complicate...

I did focus on cajaVM.eval and tried to theorically follow its process with an example as described below, with some small simplifications since security is one thing but the final result of VM processing (whether security is involved or not) is interesting too

Maybe it will be undigest for other readers since it is difficult to summarize if you do not have all the code, but again it's quite smart as js allows (even if I have some doubts about performances with all the getters and setters, and even with proxies being added later to help this), I hope my understanding is correct, the exercise is not just a "vue de l'esprit", I have something in mind since some time related to this and other things that I might submit, maybe to simplify a little bit.

function compileExpr(exprSrc, opt_sourcePosition) {
  var wrapperSrc = securableWrapperSrc(exprSrc, opt_sourcePosition);
  var wrapper = unsafeEval(wrapperSrc); //eval
  var freeNames = atLeastFreeVarNames(exprSrc);
  var result = makeCompiledExpr(wrapper, freeNames);
  return freeze(result);
}

sharedImports : copy of the global object with original properties frozen (parseInt, etc);

imports : clone of sharedImports;      //this is now our virtual global for code execution
                                                                //ex : imports.parseInt --> parseInt

window : imports; //let's call it window for better understanding, see it as a gadget's own window, not the usual global window

window.window=window; //Assign window property to window refering to itself. I did not see it in the code but probably it is somewhere

window.d="d"; //define it not frozen

window.f="f"; //define it frozen

src='var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g"';

wrapperSrc='(function() {
      with (this) {
        return function() {
          "use strict";
          return (
            var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g";
          );
        };
      }
    })';
   
wrapper=function() {
      with (this) {
        return function() {
          "use strict";
          return (
            var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g";
          );
        };
      }
    }
   
freeNames=['a','c','parseInt','d','f'];

scopeObject= { //frozen
    a: {get:scopedGet, set:scopedSet}, //set and get window.a
    c: {get:scopedGet, set:scopedSet}, //set and get window.c
    d: {get:scopedGet, set:scopedSet}, //set and get window.d
    parseInt: window.parseInt, //initial parseInt, not evil
    f: "f"
}

function() {
      with (this) {
        return function() {
          "use strict";
          return (
            var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g";
          );
        };
      }
    }.call(scopeObject)

returns :

function() {
    "use strict";
      return (
        var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g";
      );

}

whose's scope is still under the |with| statement where  :
    a: {get:scopedGet, set:scopedSet}, //set and get window.a
    c: {get:scopedGet, set:scopedSet}, //set and get window.c
    d: {get:scopedGet, set:scopedSet}, //set and get window.d
    parseInt: window.parseInt; //initial parseInt, not evil
    f: "f" //frozen initial value

Then :

function() {
    "use strict";
      return (
        var a="a";window.b="b";c="c";parseInt="evil";d="D";f="F";this.g="g";
      );

}.call(window)

//|this| does refer to window for code execution

window.a==="a"; //scopedGet result
window.b==="b"; //assignment by window property of window
window.c==="c"; //scopedGet result
window.parseInt===parseInt; //parseInt reassignment fails (frozen), scopedGet result
window.d==="D"; //scopedGet result
window.f==="f"; //frozen initial value
window.g==="g"; //|this| is window


Le 20/03/2012 06:27, Mark S. Miller a écrit :
On Mon, Mar 19, 2012 at 3:10 PM, Aymeric Vitte <[hidden email]> wrote:
'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)

Not really. I expected more resistance than I got. During the 20 minutes of lively Q&A, this came up again. I clarified then something I should have said earlier in the talk. The objects that need to be defensive are those that might be exposed across a trust boundary, such as the counter in the first example. For objects purely inside one trust domain, given that we really are confident they cannot escape, they do not need to be defensive since their clients are all presumably intimately cooperative.


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.

Sorry, but we're using these techniques in real life. And what's questionable about setTimeout? (or better, <http://dbaron.org/log/20100309-faster-timeouts>)


Then what is the use of Bob if he can not do anything outside of himself ?

Please do make an effort to surmount whatever technical difficulties you encountered, so that you can listen to the audio of the presentation. The slides were not constructed to be self explanatory, and the talk was clear on this point.

 

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)

If Alice does not trust Bob, Alice should generally never give Bob direct unmediated access to one of her dom nodes. Instead, she gives him access to a virtual dom tree that wraps the real dom tree, allowing Bob to manipulate a subtree of Alice's dom tree. We constructed the Domado library <http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/domado.js> for exactly this purpose.

The difficultly of emulating the dom faithfully in JS was also the original impetus for the proxy work. The Domado library above does not rely on proxies, as they are not yet as available as ES5.
 

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 ?

I'm sorry, I didn't understand these last two paragraphs. Could you clarify?

You might also want to try some of the scenarios you have in mind at <https://caja.appspot.com/>.


--
    Cheers,
    --MarkM

-- 
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Brandon Benvie
http://bbenvie.com/lab/shadow is an example of what you can do using Proxies (look in the console). That's loading jQuery (unmodified) into a membrane wrapping everything.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2


On Tue, May 15, 2012 at 11:45 PM, Brandon Benvie <[hidden email]> wrote:
http://bbenvie.com/lab/shadow is an example of what you can do using Proxies (look in the console). That's loading jQuery (unmodified) into a membrane wrapping everything.

What does 

    [06:40:52.788] Error: Failed to preserve wrapper of wrapped native weak map key. @ http://bbenvie.com/lab/shadow/meta-objects.browser.js:947

mean? I saw this as the first thing on the console when run on FF Nightly 15.0a1 (2012-05-05)

--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Mark S. Miller-2
Sorry, not the first thing on the console. I didn't notice the setting of the scroll bar elevator.

On Wed, May 16, 2012 at 6:44 AM, Mark S. Miller <[hidden email]> wrote:


On Tue, May 15, 2012 at 11:45 PM, Brandon Benvie <[hidden email]> wrote:
http://bbenvie.com/lab/shadow is an example of what you can do using Proxies (look in the console). That's loading jQuery (unmodified) into a membrane wrapping everything.

What does 

    [06:40:52.788] Error: Failed to preserve wrapper of wrapped native weak map key. @ http://bbenvie.com/lab/shadow/meta-objects.browser.js:947

mean? I saw this as the first thing on the console when run on FF Nightly 15.0a1 (2012-05-05)

--
    Cheers,
    --MarkM



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

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

Aymeric Vitte
In reply to this post by Brandon Benvie
I have tried it with last FF nightly build (I got the same warnings as
M. Miller reported), with a usual (messy) real web page that is mixing
about everything (jquery, other fw, js with jquery, non jquery js, etc),
the purpose was to check the impact on performances with proxies and
without proxies.

I do include shadow scripts at the begining of the page, then include a
script that waits for shadow to be executed and then load the page with
the appropriate base reference, and finally add at the end a script to
test some other things with jquery. For the tests I did remove the
shadow's console output.

- Page loading + simple tests at the end :
http://extractwidget.com/nodejs/test/shadow/shadow3.html (with shadow)
http://extractwidget.com/nodejs/test/shadow/shadow4.html (without shadow)

Results :
w/o cache : shadow4     2,3s - shadow3     4,8s
with cache : shadow4 <1s - shadow3     3.3s

- Page loading + unfair script at the end  (var
el_=$('*');el_.each(function(){for (var n in this.style)
{$(this).css(n);}});) :
http://extractwidget.com/nodejs/test/shadow/shadow3b.html (with shadow)
http://extractwidget.com/nodejs/test/shadow/shadow4b.html (without shadow)

shadow4 : 24s
shadow3 : 29s

Conclusion : apparently, if the tests are correct, proxies do not really
impact performances as I thought they would (at least FF
implementation), images of the tests are here attached (disregard the
few js errors coming from the page)



Le 16/05/2012 08:45, Brandon Benvie a écrit :
> http://bbenvie.com/lab/shadow is an example of what you can do using
> Proxies (look in the console). That's loading jQuery (unmodified) into
> a membrane wrapping everything.

--
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

shadow4b.jpg (350K) Download Attachment
shadow3b.jpg (378K) Download Attachment
shadow4-no cache.jpg (127K) Download Attachment
shadow4-cache.jpg (127K) Download Attachment
shadow3-no cache.jpg (145K) Download Attachment
shadow3-cache.jpg (144K) Download Attachment