html - Security comparison of eval and innerHTML for clientside javascript?

Question

I've been doing some experimenting with innerHTML to try and figure out where I need to tighten up security on a webapp I'm working on, and I ran into an interesting injection method on the mozilla docs that I hadn't thought about.

var name = "<img src=x onerror=alert(1)>";
element.innerHTML = name; // Instantly runs code.

It made me wonder a.) if I should be using innerHTML at all, and b.) if it's not a concern, why I've been avoiding other code insertion methods, particularly eval.

Let's assume I'm running javascript clientside on the browser, and I'm taking necessary precautions to avoid exposing any sensitive information in easily accessible functions, and I've gotten to some arbitrarily designated point where I've decided innerHTML is not a security risk, and I've optimized my code to the point where I'm not necessarily worried about a very minor performance hit...

Am I creating any additional problems by using eval? Are there other security concerns other than pure code injection?

Or alternatively, is innerHTML something that I should show the same amount of care with? Is it similarly dangerous?

Answer 1

tl;dr;

Yes, you are correct in your assumption.

Setting innerHTML is susceptible to XSS attacks if you're adding untrusted code.

(If you're adding your code though, that's less of a problem)

Consider using textContent if you want to add text that users added, it'll escape it.

What the problem is

innerHTML sets the HTML content of a DOM node. When you set the content of a DOM node to an arbitrary string, you're vulnerable to XSS if you accept user input.

For example, if you set the innerHTML of a node based on the input of a user from a GET parameter. "User A" can send "User B" a version of your page with the HTML saying "steal the user's data and send it to me via AJAX".

See this question here for more information.

What can I do to mitigate it?

What you might want to consider if you're setting the HTML of nodes is:

• Using a templating engine like Mustache which has escaping capabilities. (It'll escape HTML by default)
• Using textContent to set the text of nodes manually
• Not accepting arbitrary input from users into text fields, sanitizing the data yourself.

See this question on more general approaches to prevent XSS.

Code injection is a problem. You don't want to be on the receiving end.

The Elephant in the room

That's not the only problem with innerHTML and eval. When you're changing the innerHTML of a DOM node, you're destroying its content nodes and creating new ones instead. When you're calling eval you're invoking the compiler.

While the main issue here is clearly un-trusted code and you said performance is less of an issue, I still feel that I must mention that the two are extremely slow to their alternatives.