Security risks of using eval() to execute user input in JavaScript

Question

I\'m planning on throwing together a quick web page for my students to teach them about JavaScript programming. On this page, I\'d like to give them a text box and allow the

Answer 1

If it's on a local "Throw-away" machine, then there is very little risk. Since everything is being run client-side, they can only harm themselves with JavaScript. Worst case they could be opening Ajax connections, but that's not much more harmful than giving them a Firefox with the Tamper Data add-on.

In short, there's very little risk (except performance-wise) of giving them free-reign with JavaScript except to the machine they are using, but it's still nothing they couldn't do themselves if crafty enough. I'd recommend either having them run it on their own machines, or on a demo box that you can re-image at any time when it gets too laden with crap to continue running.

Now, giving them eval access to PHP/etc on the other hand would be a horrible, terrible idea.

Answer 2

You could try using a JavaScript sandboxing library. Dean Edward's solution Caja do not restrict code from accessing the current window or document. The JSandbox library fully sandboxes code execution using Web Worker Threads (you won't be able to use the DOM because of this) but it only works in browsers that support them.

JSandbox is asynchronous so you will need to change your code to make use of callbacks if you choose to use it.

Answer 3

I would recommend you to sandbox all the user input evaling, to prevent the evaluated code to access all of the global (window) object properties and methods.

Give a look to the following resources:

• Sandboxing JavaScript Using <iframe>
• google-caja

Answer 4

There is really no serious risk here. For example, open up firebug on this page and type in the console: eval("alert('hello');");, problem? Not really.

For demo purposes this is no big deal.

Answer 5

Well what that means is that any code a user wants to execute on your form they can and under the authority of the domain your site is running under.

So if someone wants to execute code on a machine which is locked down, but trusts your site (e.g. would allow you to run active x controls, etc. etc.), that person would have the ability to do so by typing in the correct code an using your site to eval the script into the trusted space. Essentially, by doing this, you are certifying that anything which runs on that page is verified as safe to people who trust your domain. (Think trusted sites in IE etc.)

Answer 6

The security risk you're taking, is that you're taking input from the user and running it in the context of a script on your site. Imagine if you were a malicious cracker that for whatever reason had full access to modify the JavaScript running on a website. You can do anything that JavaScript running on your domain would have the ability to do (including cookie stealing, XSS, drive-by malware, etc.).

The only thing you can realistically do to mitigate the risks is to not eval() user-provided content. Attempts to sanitise the input to only allow "safe" input are doomed to failure; it's almost impossible to define what counts as safe, and even harder to actually limit the script to that (given that the potential attacker has an interpreted language with which to disguise his intentions).

Mind you, if this is for educational purposes then one approach is just to make sure that all of the security holes don't matter. Bad JavaScript cannot destroy your server or steal money from your bank account (unless it's on your bank's web page of course). If the site hosting the page has no cookies or sessions worth stealing, and students know it's just an educational resource, I don't think there would be anything to worry about. Most of the attacks rely on accessing confidential information stored on your domain, or tricking domain visitors into giving up confidential information somehow (phishing attacks or similar). For your purposes I think you'll be OK - just don't do it on a "real" website.