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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On 10/20/06, Donut Donut <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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.http://svn.techno-weenie.net/projects/plugins/white_list/README see it in action: http://beast.caboo.se/forums/5/topics/319 -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 Kiser cynthia.kiser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Fri, Oct 20, 2006 at 11:34:21PM -0700, Cynthia Kiser 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 Kiser } cynthia.kiser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org --Greg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> (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 Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---