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.