TinyMCE security problems

http://svn.techno-weenie.net/projects/plugins/white_list/README

see it in action:
http://beast.caboo.se/forums/5/topics/319

TinyMCE has a configuration setup (valid_elements) to control what tags/attributes are allowable. Unfortunately, with the integration method currently available, the configuration stanza is visible in the page source code. So it only really prevents clueless use of blink tags; I don’t think it prevents malicious scripting. I don’t understand enough about the processing/html generation to know if one could move the valid_elements declaration and enforcement back onto the server for greater security.

Tangent: Does anyone know if FCKeditor has a similar “only allow these tags” configuration? I didn’t see one while poking around the docs, but was wondering if I just missed it.

} TinyMCE has a configuration setup (valid_elements) to control what
} tags/attributes are allowable. Unfortunately, with the integration method
} currently available, the configuration stanza is visible in the page source
} code. So it only really prevents clueless use of blink tags; I don't think
} it prevents malicious scripting. I don't understand enough about the
} processing/html generation to know if one could move the valid_elements
} declaration and enforcement back onto the server for greater security.
}
} Tangent: Does anyone know if FCKeditor has a similar "only allow these tags"
} configuration? I didn't see one while poking around the docs, but was
} wondering if I just missed it.

While it's nice and all to be able to restrict what the editor will do,
it's just like client-side validation -- you need to back it up with
server-side validation. A malicious user can submit anything at all over
the wire, regardless of the editor. (It isn't even difficult; look at the
Tamper Data extension for Firefox.)

My company is using TinyMCE, and I wrote an Hpricot-based sanitizer that
takes a tag whitelist, tag graylist, and attribute whitelist. (The
attribute whitelist is not per tag, as it is in the whitelist helper posted
earlier in this thread, because I couldn't think of a use case in which an
attribute should be allowed in one tag and not in another; if someone has
such a use case, please tell me.) Any tag not on the whitelist or graylist
goes away, including its content. Any tag on the graylist is converted to a
div. All tags that have not been removed have their attributes filtered.
There is even an opportunity to pass a block to be called on every
non-removed tag after it's been processed to do things like adding a
target=_blank to all cross-site links.

The importance of using Hpricot is that after I'm done processing I am
guaranteed that I will get an XHTML-compliant fragment. Any solution that
doesn't involve parsing the input will allow unclosed tags (by definition
-- if you are looking for open and close tags, you are parsing), and no one
wants half a page rendering in bold because some user forgot to close a b
tag.

I'd love to post the code, but bureaucratic red tape makes it unpleasantly
difficult to get permission to do so.

} Cynthia Kiser
} cynthia.kiser@gmail.com
--Greg

(The
attribute whitelist is not per tag, as it is in the whitelist helper posted
earlier in this thread, because I couldn't think of a use case in which an
attribute should be allowed in one tag and not in another; if someone has
such a use case, please tell me.)

That's a good point. I updated white_list to do this.