# TinyMCE security problems **URL:** \ **Category:** Rails\ **Created:** [October 21, 2006, 3:31am UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087 "2006-10-21T03:31:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![donut](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19adc/32.png) [@donut](https://www.ruby-forum.com/u/donut)\ **Post date:** [October 21, 2006, 3:31am UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087/1 "2006-10-21T03:31:53Z")
Hi, I’ve just integrated TinyMCE into my website. But then I started reading some Cross Site Scripting Attacks articles and now I’m worried. TinyMCE allows users to type in any HTML code and so users can write javascript and do all kinds of things such as stealing the user’s cookies. I did a search on the forum and noticed that a lot of people use TinyMCE. So my question for the TinyMCE adopters is that how you handle the potential security problems when you display the entered html on a web page? You can’t use h() to encode the html code. Is sanitize() enough to completely safe-guard the problems? Thanks a bunch for your help. ---
**Author:** ![donut](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19adc/32.png) [@donut](https://www.ruby-forum.com/u/donut)\ **Post date:** [October 21, 2006, 4:00am UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087/2 "2006-10-21T04:00:09Z")
On 10/20/06, Donut D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > on a web page? You can’t use h() to encode the html code. Is > sanitize() enough to completely safe-guard the problems? > > Thanks a bunch for your help. [http://svn.techno-weenie.net/projects/plugins/white\_list/README](http://svn.techno-weenie.net/projects/plugins/white_list/README) see it in action: [http://beast.caboo.se/forums/5/topics/319](http://beast.caboo.se/forums/5/topics/319) – Rick O. [http://weblog.techno-weenie.net](http://weblog.techno-weenie.net) [http://mephistoblog.com](http://mephistoblog.com) ---
**Author:** ![donut](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19adc/32.png) [@donut](https://www.ruby-forum.com/u/donut)\ **Post date:** [October 21, 2006, 8:40am UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087/3 "2006-10-21T08:40:19Z")
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. Cynthia K. removed\_email\_address@domain.invalid ---
**Author:** ![donut](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19adc/32.png) [@donut](https://www.ruby-forum.com/u/donut)\ **Post date:** [October 21, 2006, 2:57pm UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087/4 "2006-10-21T14:57:26Z")
On Fri, Oct 20, 2006 at 11:34:21PM -0700, Cynthia K. wrote: } 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 K. } removed\_email\_address@domain.invalid –Greg ---
**Author:** ![donut](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e19adc/32.png) [@donut](https://www.ruby-forum.com/u/donut)\ **Post date:** [October 21, 2006, 7:10pm UTC](https://www.ruby-forum.com/t/tinymce-security-problems/73087/5 "2006-10-21T19:10:16Z")
> (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. – Rick O. [http://weblog.techno-weenie.net](http://weblog.techno-weenie.net) [http://mephistoblog.com](http://mephistoblog.com)