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?
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.
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.
(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.