I originally blogged about html2dom on the Mozilla Security Blog
Having spent significant time to review the source code of some Firefox OS core apps, I noticed that a lot of developers like to use
insertAdjacentHTML). It is indeed a useful API to insert HTML from a given string without hand-crafting objects for each and every node you want to insert into the DOM.
The dilemma begins however, when this is not a hardcoded string but something which is constructed dynamically. If the string contains user input (or something from a malicious third-party - be it app or website), it may as well insert and change application logic (Cross-Site Scripting): The typical example would be a
<script> tag that runs code on the attacker's behalf and reads, modifies or forwards the current content to a third-party. CSP, which we use in Firefox OS, can only mitigate some of these attacks, but certainly not all.
Using innerHTML is bad (Hint: DOM XSS)
What's also frustrating about these pieces of code is that analyzing it requires you to manually trace every function call and variable back to its definition to see whether it is indeed tainted by user input.
With code changing frequently those reviews don't really scale. One possible approach is to avoid using
innerHTML for good. Even though this idea sounds a bit naive, I have dived into the world of automated HTML parsing and code generation to see how feasible it is.
<p id="greeting">Hello <b>World</b></p>
Will yield this (as a string).
var docFragment = document.createDocumentFragment(); // this fragment contains all DOM nodes var greeting = document.createElement('P'); greeting.setAttribute("id", "greeting"); docFragment.appendChild(greeting); var text = document.createTextNode("Hello "); greeting.appendChild(text); var b = document.createElement('B'); greeting.appendChild(b); var text_0 = document.createTextNode("World"); b.appendChild(text_0);
As you can see, html2dom tries to use meaningful variable names to make the code readable. If you want, you can try the demo here. Now we could also just replace the
When it comes to HTML parsers, you also don't want to write your own.
I have also written a few unit tests, so if you want to start messing with my code, I suggest you start by checking them out right away.
Known Bugs & Security
This tool doesn't really save you from all of your troubles. But if you can, make sure that the user input is always somewhere in a text node, then html2dom can prevent you from a great deal of harm. Give it a try!
On the horizon