Are you worried about eval function redefinition?
Are you worried about whatever you want redefinition?
STOP
With the incredible eval feature "discovered" few days ago, it possible to create the most safe environment ever for every kind of purpose, starting from JSON evaluation, arriving to total protected native constructors.
const safeEnvironment = function(A, B, D, F, N, O, R, S){
const Array = A,
Boolean = B,
Date = D,
Function= F,
Number = N,
Object = O,
RegExp = R,
String = S,
eval = function(String){
return self.eval("(" + String + ")");
};
return new function(){};
}(
Array,
Boolean,
Date,
Function,
Number,
Object,
RegExp,
String
);
With above piece of code you can evaluate every kind of script without to be worried about common XSS or evaluation problems.
eval("Array=function(){}; alert(Array);", safeEnvironment);
/*
function Array(){
[native code]
}
*/
Seems to be hilarious, isn't it? The most scary Gecko function let us redefine entirely an environment, using constants to create immutable values that will be present in the virtual sandboxed scope.
So, the paradox, is that with Gecko eval, we could create the perfect safe environment, that could be used for every purpose, starting from the NoScript stuff.
Please, help me to convince Mozilla staff that second argument is not dangerous and could make our code execution safer than ever, thank you!
We can do great things with this second parameter of eval.
ReplyDeleteBut what about that?
eval("window.Array=function(){}; alert(window.Array);", safeEnvironment);
and...
eval("x=document.body.appendChild(this.document.createElement('iframe')); x.contentWindow.eval('evilCode')", safeEnvironment);
tobi, your tricks that works right now with or without second arguments, do not affect native environment functions.
ReplyDeleteThis means that every time you use something like
var arr = [1,2,3];
or you evaluate a JSON string, the native array will be preserved, it does not matter if you changed the window one using explicit keyword ;)
Andr3a, why did you suggest mozilla to introduce the "sandbox" keyword (or function) that do exactly what you're expecting from your function ?
ReplyDeleteI think that leave out the 2 not standard parameter on eval isn't this big issue as long we have a good sandbox to play.
If I am not wrong, XUL has just a sandbox similar method, but since the problem is not the second argument, but its capability to grab private scope informations, they will never implement what you are talking about.
ReplyDeleteI hope they will change their mind, but until now, the bug has been REOPENED - so it is a start point :)