spec proposal: HTML sanitizer

[Brian Eaton]

This has come up a few times, but I don't think anyone has proposed it
yet for opensocial-0.8.

The gadgets.util library should include a simple function to sanitize
arbitrary text into a subset of HTML that cannot execute script.

/**
* Sanitizes a text string. The returned value is safe to assign to innerHTML.
* The returned value may include HTML tags. If plain text is desired, use
* gadgets.util.escapeString instead.
*
* @param {String} text arbitrary text string
* @return {String} a sanitized version that may include HTML tags,
but will not execute script.
*/
function gadgets.util.sanitizeHtml(text) {
...
}

[Zhen Wang]

What specific HTML tags are whitelisted by this function?

[Brian Eaton]

On Sat, Apr 19, 2008 at 5:34 PM, Zhen Wang <wa...@google.com> wrote:
> What specific HTML tags are whitelisted by this function?

I'm not sure. =)

I think the function should allow as many tags and attributes as
possible without permitting any kind of javascript/flash/applet/other
active content to sneak in. The Caja HTML sanitizer seems like it
should provide a baseline for this.

I don't think the spec should include a list of specific tags and
attributes, that would restrict our ability to expand tag whitelists
in the future.

[Kevin Brown]

+ 1

I'll add that we shouldn't just be using caja as a reference point, we should be ensuring compatibility with it. If we're only filtering "bad" stuff, legitimate impact will be slight, and good documentation on what the function filters will let legitimate uses of "bad" stuff can work around it by doing an escape / filter / unescape routine.

[Michael Mahemoff]

+1

Very useful for inter-user messaging and the like. Ideal would be for the function to include a parameter to further constrain the list of possible tags/attribs.

[Cassie]

Okay so Brian, Kevin and Michael are for this. (= 3 votes)

Adding Louis because he was looking for this in another thread.
Adding Zhen so that he can say whether his question was resolved by Brian's answer.

- Cassie

[Lane LiaBraaten]

+1

[Graham Spencer]

+1

[Kevin Marks]

+1
In fact I'd support even more strongly Graham's safeSetInnerHTML - ie fixing this problem at the point of vulnerability, rather than trying to guess which other sources of strings might eventually end up in the page and playing whack-a-mole on them.

[Cassie]

spec approved.
thanks.

- cassie