在包含富文本编辑器的HTML小节中限制Javascript

Question

I'm working on a legacy web app that uses both the rich-text summernote editor , which can save formatted notes to our server, as well as a lot of instances of in-line Javascript.

Summernote can permit writing HTML/CSS/JS via it's "code" view, but doesn't seem to have any built-in support for preventing XSS. If you go to their homepage for instance, go to code-view for the editor, and write <script>alert(0)</script> and turn it back to text-view, it will execute the script. We want users to be able to do things like bold content, insert hyperlinks & images, etc, but no JS or probably even CSS.

We've just discovered the developer who originally implemented XSS protection for these editors in the app did a bit of a weak job, and are now trying to sure it up. Thus far, it seems my options are either: (a) creating/sourcing a whitelist which will parse the Summernote HTML and only allow certain HTML elements in the field; and/or (b) implementing CSP headers and moving all in-line JS / CSS to separate files.

Given it's only these editors that need to be able to return valid HTML to users, the rest of the site we can and do fully sanitize content, is it possible to disable inline JS / CSS in only a section of an HTML page (Ie the area we load the editor's content to)? Or is that not an option / liable to be susceptible to workarounds?

Edit : Just as a note, I recognize that the rich-text editor can't prevent XSS if we're choosing to save content to the server, as it runs on the client-end. I meant that I couldn't find resources / suggestions regarding HTML whitelists, or example sanitization for various servers via their site.

Edit 2 : Will definitely be implementing some sort of whitelist to be on the safe-side (possibly CSP as well, but refactoring will be a headache), but still want to know if this is possible: Ie between two sections of HTML, is it possible to block all inline JS & CSS?

Answer 1

As I read in this note https://github.com/summernote/summernote/issues/1617

You have to validate at serverside anyway. It's a funny behavior, I agree, but the user is allowed to do anything in his own browser. The only thing you (you, and not this package) should taker care of, is not letting users storing harmful code in your database (which is later displayed in other users browser)

So, basically you are in charge of what users are trying to put in your database or web page. So you need to:

• Make a "server-side" validation of the content (delete <script> tags with content, for example)
• Implementing a client-size sanitization (it does not prevent you to make a server-side validation) to help the user notify he is not allowed to include scripts. This could be done while switching between code view and preview (See Summernote event for switch from code view to editor )