SCARY EVAL ... and the "futuristic" solution
Planet Earth, Year 2000
Satellite Moon, Year 2004
Planet Earth 2.0, Year 2008
OMG somebody could penetrate my closures!!!
Web Reflection, few days later
First of all, it was in the MDC, so if everbody is surprised, it is because we did not read that page, or simply we did not try that code (please correct that page, the second argument is everything but not the same of with statement).
Secondly, please, DO NOT CHANGE THAT FEATURE!!!
What I mean is that JavaScript is an amazing language, where everything could be changed, thanks to its intrinsically dynamic nature.
If we are worried about this fake news:
The feature is present in Gecko, but hey, Gecko implements constants!!!
Another thing I could not understand, is why somebody opened a bug for a feature that could be AMAZING if used for our own purpose.
Code and closure introspections, protected method implementation, whatever I cannot imagine right now.
On the other hand, it is extremely simple to solve the problem using a basic constant declaration
Now try to delete the constant, try to do whatever you want in FireFox, and if it will be possible to change that $eval behaviour with Gecko browser, that will be the only bug you should really fix.
With Best Regards,
your bloody evil propagator ( booh! )
Update
Since I am writing in the bug page, I think my example could be interesting to understand what we are going to loose when this feature will disappear:
These are only two quick examples, and I wrote them in 1 minute.
Now try to imagine what could be possible to do having such control over closures!
eval("document." + myformName + "." + myInputName + ".value");
Satellite Moon, Year 2004
eval is evil, nobody should use them, "except for json evaluation"
Planet Earth 2.0, Year 2008
OMG somebody could penetrate my closures!!!
Web Reflection, few days later
First of all, it was in the MDC, so if everbody is surprised, it is because we did not read that page, or simply we did not try that code (please correct that page, the second argument is everything but not the same of with statement).
Secondly, please, DO NOT CHANGE THAT FEATURE!!!
What I mean is that JavaScript is an amazing language, where everything could be changed, thanks to its intrinsically dynamic nature.
If we are worried about this fake news:
- we should worry, before, about XSS in our site (after SQL injections)
- if we are sure about missed XSS possibility, we should be worried about external libraries
- if we are sure about third parts libraries, we should be worried about JSON
- if we are sure about external libraries and JSON interactions ... why on heart should we be worried about this historic feature?
The feature is present in Gecko, but hey, Gecko implements constants!!!
Another thing I could not understand, is why somebody opened a bug for a feature that could be AMAZING if used for our own purpose.
Code and closure introspections, protected method implementation, whatever I cannot imagine right now.
On the other hand, it is extremely simple to solve the problem using a basic constant declaration
// webreflection "from the space"
try{eval("const $eval=function(eval){return function($eval){return eval($eval)}}(eval)")}catch($){$eval=eval};
Now try to delete the constant, try to do whatever you want in FireFox, and if it will be possible to change that $eval behaviour with Gecko browser, that will be the only bug you should really fix.
With Best Regards,
your bloody evil propagator ( booh! )
Update
Since I am writing in the bug page, I think my example could be interesting to understand what we are going to loose when this feature will disappear:
// sandbox: redefined environment
var myEnvironMent = {
eval:function(script){
return eval(script);
},
alert:function(String){
(document.body || document.documentElement)
.appendChild(document.createTextNode(String));
}
};
// evaluate a script from a string or a textarea
eval("alert('Hello World')", myEnvironMent);
/* you cannot do this with a with statement
with(myEnvironMent)
eval("alert('Hello World')");
*/
// privileged protected methods in prototype
Protected = function(){
function _showMessage(message){
alert(this.name.concat(" say ", message));
}
return function(name){
this.name = name;
};
}();
Protected.prototype._ = function(method){
return eval("_" + method, this)
.apply(this, Array.prototype.slice.call(arguments, 1));
};
var p = new Protected("Andrea");
p._("showMessage", "Hello World");
These are only two quick examples, and I wrote them in 1 minute.
Now try to imagine what could be possible to do having such control over closures!
Comments
Post a Comment