Security

Client Side

Scenario: Content that is copy & pasted into the editor could contain scripts or styles that have an immediate affect on page functionality. Such content could even perform cookie stealing while the user is working with the editor.

Solution: wysihtml5 relies on a three-layered security model:

1. Browser: Modern browsers already sanitize content before inserting it into rich text editors. Unfortunately Internet Explorer isn’t good at that. (see tests)
2. iframe: wysihtml5 is always rendered in a sandbox iframe. The iframe disallows javascript from being executed in IE (by using its proprietary security attribute). In non-IE browsers sensitive variables (such as document.cookie, window.parent, localStorage etc.) are protected via setters/getters
3. HTML5 Parser: The default HTML5 parser rules strip out potentially malicious HTML (such as <script>, <iframe>, meta redirects, …)

Server Side

Scenario: An attacker can always omit wysihtml5’s client side security barrier and post malicious HTML to the server.

Solution: A HTML sanitizer needs to be used on the server unless wysihtml5 is used in a trusted environment (eg. CMS where only people with permissions can interact with wysihtml5).

Here’s an incomplete list of proven HTML sanitizers:

• Perl: HTML5::Sanitizer (uses the same parser rule definitions as wysihtml5)
• Ruby: sanitize
• Python: Bleach
• PHP: HTML Purifier
• .NET: sanitize
• Java: owasp-java-html-sanitizer
  Please note: Only use html sanitizers that do whitelisting instead of blacklisting