2

Maybe I'm missing something obvious here... The development landscape is littered with client-side WYSIWYG text editors (for example, TinyMCE), all of which seem to want to send raw HTML back to my server via something like a textarea. The obvious challenge with a scheme like this is that, even if the editor can be trusted not to produce malicious HTML, it's trivial for a hacker to inject malicious HTML into a POST back to my website.

What am I missing? Does everyone who uses one of these client-side text editors attempt to "sanitize" the ingested HTML to remove malicious content? That would seem to be a losing game between the website and the bad guys, who are always coming up with creative constructs designed to elude HTML cleaners.

So, just thinking out loud here... For my project, I just need super-simple formatting (bold, italic, maybe bulleted lists). Some options for dealing with untrusted HTML-formatted text might be:

  • Somehow Cryptographically authenticate the HTML textarea content to prove that it was generated by trusted JavaScript in the browser?

  • The server could convert the ingested HTML to a "safe" format such as markdown. Presumably, the conversion process would be immune from attack because its output is a format that can be stored and later rehydrated to safe HTML for display on the website.

EDIT:

As at least one commenter has noted, it's possible to trick markdown into emitting malicious HTML. By extension, any rich text format that converts to HTML which is directly included in the web page is subject to a similar class of attacks. So my "convert the HTML to a 'safe' format" option is no better than simply trying to sanitize the uploaded HTML.

I would think that there should be some way to guarantee that all JS content is removed from the uploaded HTML. Obviously, browser engines recognize (and execute) sneaky JS. It should be easy enough to write some code that answers the question: "Is there any JS in this HTML snippet?" (Even better would be a <nojs> HTML tag that tells browsers not to execute any JavaScript that appears in its inner HTML, including HTML pulled in from <iframe> elements. I wish...)

Improve this question
8
  • "it would be great if I could find a simple WYSIWYG editor that emits markdown rather than HTML" - A simple search for wysiwyg editor markdown should provide you with several options. But product recommendations are off-topic here, so better remove this part from your question.
    – Steffen Ullrich
    Commented Sep 3, 2019 at 17:49
  • 1
    Since I don't want to handle the complete question just a note about this part: "Somehow Cryptographically authenticate the HTML textarea content to prove that it was generated by trusted JavaScript in the browser?" - I don't think that this can be done since an attacker might modify this script to both claim that it has generated this HTML and to also claim that it is still the unmodified script. I think the best option in your use case is having some wysiwyg markdown editor.
    – Steffen Ullrich
    Commented Sep 3, 2019 at 17:56
  • Yeah, I was hoping that I could sneak in the request for a product recommendation... as I noted in the original post, all of the markdown editors seem to want the user to actually enter markdown-formatted text. The "WYSIWYG" part is just a real-time display of the formatted result. So where is an appropriate forum to pose the "product recommendation" question?
    – Bob.at.Indigo.Health
    Commented Sep 3, 2019 at 19:27
  • You might try Software Recommendations.
    – Steffen Ullrich
    Commented Sep 3, 2019 at 20:35
  • Never ever consider any other format than HTML as a complete workaround for security concerns. In the end markdown is translated to HTML so it has the same issues, also some/most markdown libraries simply allow for HTML. See e.g. medium.com/taptuit/exploiting-xss-via-markdown-72a61e774bf8 and just google markdown + XSS.
    – Wiktor Walc
    Commented Sep 4, 2019 at 14:44

1 Answer 1

Reset to default
1

Somehow Cryptographically authenticate the HTML textarea content to prove that it was generated by trusted JavaScript in the browser?

This is a no go. For the client to sign something, it would need the key. And you can't trust the client with the key. Off course you could have the server do the signing, but then you are back to square one again...

The server could convert the ingested HTML to a "safe" format such as markdown.

This sounds like the way to go. Convert it to markdown, strip any HTML tags. Then convert it back to HTML and perhaps run it through a HTML purifyer to make sure there are nothing but i and b and so on in there.

Off course, it would be simpler with an editor that just produce markdown in the first place.

Improve this answer
4
  • Just pulling on the "cryptographic authentication" string a bit... Many of the HTML editors operate by constructing an iframe and talking directly to the vendor's server. In that case, couldn't the vendor's server sign the HTML payload returned by the iframe? Then my server could authenticate the signature using the vendor's public key.
    – Bob.at.Indigo.Health
    Commented Sep 4, 2019 at 5:13
  • @Bob.at.Indigo.Health Yeah, but how does the vendor know that the input comes from a real client and not a curl request? Off course the vendor could check that the HTML is "safe", but would you trust the vendors checks to be correct?
    – Anders
    Commented Sep 4, 2019 at 6:03
  • And as Wiktor Walc commented above, even markdown can be tricked into producing malicious HTML. Sigh...
    – Bob.at.Indigo.Health
    Commented Sep 5, 2019 at 0:11
  • @Bob.at.Indigo.Health That's why you should run the output through a HTML purifyer.
    – Anders
    Commented Sep 5, 2019 at 0:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .