Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Security comparison of eval and innerHTML for clientside javascript?

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?

like image 581
danShumway Avatar asked May 31 '13 14:05

danShumway


People also ask

Is innerHTML a security risk?

'innerHTML' Presents a Security RiskThe use of innerHTML creates a potential security risk for your website. Malicious users can use cross-site scripting (XSS) to add malicious client-side scripts that steal private user information stored in session cookies. You can read the MDN documentation on innerHTML .

Does innerHTML prevent XSS?

To avoid the automatic encoding of React, the developer has to assign the data to the innerHTML attribute directly. However, doing so carelessly will cause XSS vulnerabilities. That's why React exposes the innerHTML attribute through the dangerouslySetInnerHTML property.


1 Answers

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.

like image 113
Benjamin Gruenbaum Avatar answered Sep 17 '22 15:09

Benjamin Gruenbaum