As suggested in #51097: script tags vanish, having two functionalities for removing invalid HTML elements is totally error-prone and we can safely rely on Drupal's input filter system only.

According to http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements, we just need to set or replace valid_elements with *[*], and at least TinyMCE will stop filtering the user input.

Of course, there is one security issue with that: If a malicious user enters some evil JavaScript code into a content, and another user (maybe uid 1 (!)) edits this content afterwards, this could lead to a serious security hole, because the content is directly loaded and executed on behalf of the editing user.

So, while the first part would be very helpful and easy to implement, the second part needs a thorough and secure treatment.

Comments

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

Hi Sun,

* Can you please explain to me the steps involved in setting or replacing the valid_elements? Even after reading the document on TinyMCE's site I can't seem to find where / how to do this. That would be really helpful!

* Regarding the security issue - but isn't this already the case with Drupal's 'Full HTML' input format (which doesn't strip-out script tags)? And can't that be handled by using 'Filtered HTML' by default and only giving Full HTML privileges to trusted users in a particular role?

:) Scott

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

If you do not know how to implement this configuration option, then you better should not try to do it all. Heine, Drupal Security Team Leader, has a great example for you that uncovers what a malicious user was able to do if your wysiwyg editor would not filter out script tags.

Without a special integration, Drupal's filter system will not be invoked, because all rules of an input format are applied upon output of a content - while the original content stays the same. For example, above XSS example would be stripped from the output, but not from the form field on the edit page. A wysiwyg editor not filtering the contents of this field would simply execute the payload, and hence, change the password of the superuser, if uid 1 was editing this content.

I'm not really sure how to proceed from here, but will definitely think about all of this.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

hi sun,

thanks for clarifying - yikes!

instead, is there a way to add javascript to the node body using a theme function?
kind of like drupal_add_js() except to a particular php script placed within the body, like print $mycustomjs

This is probably documented elsewhere, but if this is something that can be done then hopefully we can just reserve php input format for trusted users and allow addition of js this way?

does that make sense? (if so, is there a tutorial somewhere on how to do this?)
:) Scott

sinasalek’s picture

sinasalek commented
Component: Wysiwyg Editor » Code

subscribed

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (won't fix)

This idea was bogus. Entirely bogus. Someone slap me for it, plz. :P