http://webreflection.blogspot.com/2008/07/scary-eval-and-futuristic-solution.html

I can’t find any holes in the solution, yet. But with this topic, I’ve already been burned by speaking too soon, so I’m cautiously optimistic.

Also, apparently FF3.1 is going to disable this “bug” (ie, feature), to the dismay of some, including Andrea. I agree that it should be kept and has some really interesting benefits for introspection of closures and such. Again, my original idea is that we could make a “smarter” eval where it would default to allowing access, but objects instances could specifically opt themselves out in some way, and the smart eval would respect that request.

That way, most objects could benefit from it, and those which really need to keep things “private” for some reason could in fact do that.

http://groups.google.com/group/google-caja-discuss/msg/ead8d8597a22c013

But, two things: First of all, this syntax is incompatible with IE. So, to use it, all developers would have to browser sniff and return a different patterned public API for IE users (which don’t have the dang eval problem) than for FF and others. This could work.

But also, and more troubling, would be that the public API for a module could not contain anything other than functions which set or retrieved values, using the pattern you’ve suggested. For instance, general functions which were intended to be able to have several parameters passed to them, and have some kind of operations done on them, would not be possible, as they would automatically open up the eval vulnerability. But, the set prop() functionality could only be used to pass in a single parameter, which means that any function which needed to pass in multiple values would have to do so by wrapping them in an array or object syntax. This would mean that to keep the calling code from having to have browser-specific functioning, the API calls would all have to be kind of awkward, using the object/array wrap syntax for all parameters.

Both these limitations seem possible to leverage for most “modules”. But it certainly makes things a lot uglier. :(

var obj = function(){
var a = 21;
return {
prop : undefined,
get prop(){return a},
set prop(x){
if ((typeof x === “function”) || (typeof x === object)) {
return false;
}
else {
a = x;
}
}
}
}();

var obj = function(){
var Priv = function(){
var a = 21;

return {
getA : function(){
return a;
}
}
}();

return {
fn: function(){
return Priv.getA()
}
}
}();

alert(obj.fn()) //21
var foo;
eval(“foo=Priv”, obj.fn);
alert(foo); //[object Object]
alert(foo.getA()) //21
eval(“foo=a”,foo.getA)
alert(foo) //21

var obj = (function() {
var Private = function(){
var a = 21;

return {
getA : function(){
return a;
}
}
}

return {
fn: function(){
return Private.getA();
}
}

})();

var foo;
eval(“foo=Private”, obj.fn);
alert(foo);

eval(‘foo=b’,obj.fn) and get directly at your internal, “private” variable b, either gettings it’s value into foo, or eval(‘b=500′,obj.fn) and change your internal variable without you being in control. This is the bad thing. :(

var obj = (function() {
var b = 21;
function a(){
return b;
}
return {
fn: a
};
})();

var foo;
eval(‘foo=a’, obj.fn);
alert(foo);

it now appears from my further testing that in fact this dang parameter gives full access to the entire *private* scope, regardless of the presence of closure or anything. just one publicly exposed function, even an anonymous, empty one without any closure ties to the internals, grants eval() full read/write access to the entire internal scope of your module. ugh. i give up. :)

This means that the “security” vulnerability is significantly abated in that all a hacker can do is see what the values are (which they can probably do by view-source anyway!) but they cannot change the values, at least from what I’ve tested so far.

< _root.childNodes.length; i++) {
try { _root[i].eval = s_eval; _recurseDOM(_root[i]); } catch (err) { }
}
}
catch (err2) { }
})(document.getElementsByTagName(“html”));

})();

var obj = (function() {
var a = 21;
return {
fn: function() {a;}
};
})();

(function(){
var _eval = eval;
var s_eval = eval = function(str) {
_eval(str);
}
this.__defineGetter__(“eval”, function(){
return s_eval;
});
window.__defineSetter__(“eval”, function(val){
alert(‘not allowed’);
});
var _oldCE = document.createElement;
document.createElement = function(type) {
var obj = _oldCE(type);
obj.contentWindow.eval = s_eval;
}
window.eval = s_eval;
(function recurseDOM(_root) {
if (typeof _root === undefined || _root === null) return;

try {
for (var i=0; i

You are right, its not possible to make it not work.

I tried this:
(function() {
var _eval = eval;
var s_eval = eval = function(str) {
_eval(str);
}
this.__defineGetter__(“eval”, function(){
return s_eval;
});
window.__defineSetter__(“eval”, function(val){
alert(‘not allowed’)
});
})();

but you can allways:

document.getElementById(‘test’).contentWindow.eval(‘foo=a’, obj.fn)

Yours is tidier and “delete” is a language operator so would be hard or impossible to secure. There are probably many ways to workaround any patch attempting to secure “eval”.