but then again, the list of problems is massive here if it's about
trustiness.
Object.prototype can be enriched or some method changed, parseInt and
parseFloat can be redefined to change payment details and stuff,
String.prototype.trim can be faked to read all written fields before these
are sent if the app does the cleanup, Function.prototype.apply/call can be
redefined too so access to "unknown functions" is granted again ... and all
we worry about is a caller able to access without changing a thing a
possibly unknown and private scope that if executed all it could do is
causing an error?
I am sorry but this looks/sounds/feels like an academic exercise without
concrete and reasonable facts on where this can be a problem. Drop call and
apply too then or think about putting back the powerful caller please,
thanks.
Here how any function can be trapped somewhere else, invoked, and analyzed,
during an app lifecycle.
'use strict';
(function(FunctionPrototype){
function analyze(callback, method, args) {
alert([
callback,
method,
cBound([].slice, args)
].join("\n"));
return aBound(callback, args);
}
function call() {
return analyze(this, 'call', arguments);
}
function apply() {
return analyze(this, 'apply', arguments);
}
var
$call = FunctionPrototype.call,
cString = "" + $call,
cBound = $call.bind($call),
$apply = FunctionPrototype.apply,
aString = "" + $apply,
aBound = $apply.bind($call)
;
call.toString = function toString() {
return cString;
};
apply.toString = function toString() {
return aString;
};
FunctionPrototype.call = call;
FunctionPrototype.apply = apply;
}(Function.prototype));
// test
(function(){
var pvt = {};
function test(a, b) {
return this.sum = a + b;
}
alert(test.call(pvt, 1, 2)); // 3
alert(pvt.sum); // 3
}());
Best Regards
On Sat, Mar 9, 2013 at 3:58 AM, Jorge Chamorro <jo...@jorgechamorro.com>wrote:
> On 09/03/2013, at 00:54, Andrea Giammarchi wrote:
>
> > Mark,
> > that is an exhaustive list of links and talks but how many real use
> cases where we let the user inject any sort of script code in the website
> and we inject malicious libraries we are not aware, compared with the
> number of all website that would never suffer any problem with this ?
> >
> > Comparing Java Applets with JavaScript is a no-go, Java had privileged
> access to the system, nothing caller could achieve in all it's possible
> evil forms, neither eval could do much there.
> >
> > I think there are no real use cases where caller is dangerous if not few
> academic purpose attempts to make it safer, and you seemed to work in
> probably all of them ... ask devs out there how many are using those
> libraries.
> >
> > As summary, you ask us to bring real cases where caller is needed, I
> would do the other way around: bring real cases in the real world where
> caller could be such disaster because trusting user inputs and blindly
> include external libraries are not, again, real world use cases ... not the
> majority of them, am I wrong ?
> >
> > I see this like "don't use SQKL ever because there could be SQL
> injections" ... sense? None for me :-/
>
> I think the key terms are "cooperation under mutual suspicion", "mashups",
> and "object capability": the idea is that you'd *want* to be able to run
> untrusted possibly evil code side by side with your code in your page (e.g.
> an ad and a payment gateway).
>
> Other links:
>
> Gears and the Mashup Problem: <http://www.youtube.com/watch?v=qfBL2sc2zUU/
> >
> Web Forward: <http://www.youtube.com/watch?v=yh7TeoEwNyI#t=15m40s>
> Securing JavaScript: <http://www.youtube.com/watch?v=T6TTQoqln7c>
>
> We'd much rather play with unloaded guns than in hopes that nobody else
> pulls the trigger?
> --
> (Jorge)();
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
