我们想让我们的用户能够在我们的应用程序中执行自己创建的 JavaScript 代码。为此，我们需要使用 eval 来评估代码。为了将所有安全问题降至最低(如果不是零)，我们的想法是防止在代码中使用任何 window 或 document 函数。所以没有 XMLHttpRequest 或类似的东西。

这是代码:

function secure_eval(s) {
    var ret;

    (function(){
        var copyXMLHttpRequest = XMLHttpRequest; // save orginal function in copy

        XMLHttpRequest = undefined; // make orignal function unavailable

        (function() {
            var copyXMLHttpRequest; // prevent access to copy

            try {
                ret = eval(s)
            } catch(e) {
                console.log("syntax error or illegal function used");
            }

        }())
        XMLHttpRequest = copyXMLHttpRequest; // restore original function
    }())
    return ret;
}

工作原理如下:

secure_eval('new XMLHttpRequest()'); // ==> "illegal function used"

现在我有几个问题:

1. 这种模式是确保 eval 安全的正确方法吗？
2. window 和 document 的哪些功能被认为是有害的？
3. 为了解决问题 2。我试图屏蔽 window 的所有( native )功能，但我无法枚举它们:

例如，这没有列出 XMLHttpRequest:

for( var x in window) {
    if( window[x] instanceof Function) {
        console.log(x);
    }
}

有没有办法得到window和document的所有原生函数的列表？

编辑:

我的一个想法是在 Worker 中执行 eval 并阻止访问 XMLHttpRequest 和 document.createElement(见我上面的解决方案)。这将(在我看来)产生以下后果:

• 无法访问原始文档
• 无法访问原始窗口
• 没有机会与外部资源通信(没有 ajax，没有脚本)

你看到这里有什么缺点或漏洞吗？

编辑 2:

同时我找到了this question哪个答案解决了我的许多问题以及一些我什至没有想到的事情(即浏览器死锁 "while(true){}"。

最佳答案

您的代码实际上并没有阻止使用 XMLHttpRequest。我可以使用这些方法实例化一个 XMLHttpRequest 对象:

secure_eval("secure_eval = eval"); // Yep, this completely overwrites secure_eval.
secure_eval("XMLHttpRequest()");

或者:

secure_eval("new (window.open().XMLHttpRequest)()")

或者:

secure_eval("new (document.getElementById('frame').contentWindow.XMLHttpRequest)()")

这第三种方法依赖于页面 HTML 中存在的 iframe，有人可以通过在浏览器中操作 DOM 来添加它。我时不时地使用 Greasemonkey 进行此类操作，以消除烦恼或修复损坏的 GUI。

这花了我大约 5 分钟的时间才弄明白，而且我绝不是安全大师。这些只是我能够快速找到的漏洞，可能还有其他我不知道的漏洞。这里的教训是，通过 eval 保护代码真的很难。

使用 worker

好的，所以使用 Worker 来运行代码将处理上面的第 2 和第 3 种情况，因为在 Worker 中没有可访问的窗口。而且...嗯...第一种情况可以通过在其范围内隐藏 secure_eval 来处理。故事结局？如果只是...

如果我将 secure_eval 放入 web worker 并运行以下代码，我可以重新获取 XMLHttpRequest:

secure_eval("var old_log = console.log; console.log = function () { foo = XMLHttpRequest; old_log.apply(this, arguments); };");
console.log("blah");
console.log(secure_eval("foo"));

原理是重写在secure_eval 之外使用的函数，通过将其分配给将被故意泄露的变量来捕获XMLHttpRequest到worker的全局空间，等待secure_eval外的worker使用该函数，然后获取保存的值。上面的第一个 console.log 模拟在 secure_eval 之外使用被篡改的函数，第二个 console.log 显示该值已被捕获。我使用了 console.log 因为为什么不呢？但实际上，全局空间中的任何函数都可以这样修改。

实际上，为什么要等到 worker 可能会使用我们篡改的某些功能？这是访问 XMLHttpRequest 的另一种更好、更快的方法:

secure_eval("setTimeout(function () { console.log(XMLHttpRequest);}, 0);");

即使在 worker 中(使用原始 console.log)，这也会将 XMLHttpRequest 的实际值输出到控制台。我还会注意到传递给 setTimeout 的函数中 this 的值是全局范围对象(即 window 当不在 worker 中时，或 worker 中的 self)，不受任何变量阴影的影响。

这个问题中提到的另一个问题呢？

解决方案如何here ？好多了，但在 Chrome 38 中运行时仍然存在漏洞:

makeWorkerExecuteSomeCode('event.target.XMLHttpRequest', 
    function (answer) { console.log( answer ); });

这将显示:

function XMLHttpRequest() { [native code] }

再说一遍，我不是一心想制造麻烦的安全专家或骇客。可能还有更多我没有考虑的方法。

关于javascript - 保护 JavaScript eval 函数，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26482268/