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 injec

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.

Answer 2

The quick answer is: you did not think of anything new. If anything, do you want an even better one?

<scr\0ipt>alert("XSSed");</scr\0ipt>

The ground, bottom line is that there are more ways to trigger XSS than you think there is. All the following are valid:

• onerror, onload, onclick, onhover, onblur etc... are all valid
• The use of character encoding to bypass filters (null byte highlighted above)

eval falls into another category, however - it is a byproduct, most of the time to obfuscate. If you're falling to eval and not innerHTML, you're in a very, very small minority.

The key to all this is to sanitize your data using a parser that keeps up to date with what pen testers discover. There are a couple of those around. They absolutely need to at least filter all the ones on the OWASP list - those are pretty much common.

Answer 3

innerHTML isn't insecure in and of itself. (Nor is eval, if only used on your code. It's actually more of a bad idea for several other reasons.) The insecurity arises in displaying visitor-submitted content. And that risk applies to any mechanism with which you embed user-content: eval, innerHTML, etc. on the client-side, and print, echo, etc. on the server-side.

Anything you put on the page from a visitor must be sanitized. It doesn't matter a great deal whether you do it when the initial page is being built or added asynchronously on the client-side.

So ... yes, you need to show some care when using innerHTML if you're displaying user-submitted content with it.