[whatwg] innerStaticHTML

[Adam Barth]

Rob and I were discussing the use case for IE8's toStaticHTML API and
thought it might make sense to standardize a more robust and
future-proof API for the same use case.

USE CASE

I receive an untrusted string, for example a weather report or a
Twitter status update, from postMessage or a cross-origin
XMLHttpRequest, and I want to display its content to the user without
getting XSSed.

WORKAROUNDS

If the content is purely text (e.g., no images, styles, or
hyperlinks), then I can create a text node containing the string and
insert it into my page's DOM.  If the content is not purely text, I
need to implement an XSS filter in JavaScript (which folks commonly
screw up).

PROPOSAL

In addition to innerHTML, DOM elements should expose an
innerStaticHTML property.  When set, innerStaticHTML should behave the
same as innerHTML except that scripts should not execute (even in
event handlers) and plug-ins should not be created.

EXAMPLE

<script>
fetchMostRecentTweetFor("whatwg", function (tweet) {
  document.getElementById("whatwg_tweet).innerStaticHTML = tweet;
});
</script>

WHY NOT toStaticHTML?

toStaticHTML addresses the same use cause by translating an untrusted
string to another string that lacks active HTML content.  This API has
two issues:

1) The untrusted string -> static string -> HTML parser workflow
requires the browser to parse the string twice, introducing a
performance penalty and a security issue if the two parsing aren't
identical.

2) The API is difficult to future-proof because future versions of
HTML are likely to add new tags with active content (e.g., like the
<video> tag's event handlers).  Either we'll have to commit to a
toStaticHTML algorithm that will be secure in all future versions of
HTML, or we'll have to change the input-output behavior of
toStaticHTML in future versions of HTML.

innerStaticHTML addresses the same use case without these issues.

Adam