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 <[email protected]
<mailto:[email protected]>> 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 : [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
