Is it OK for an API to not sanitize Editor.js documents?

[cmeeren]

I am a back-end developer focusing on web APIs for our front-end. The front-end uses Editor.js.

One way to look at it, from an API perspective, is that the API does not receive and return HTML to be displayed as-is on the client. Instead, the API receives and returns a custom JSON format. Sure, some parts of the JSON contain HTML. But the JSON can't be displayed directly as HTML; it requires custom front-end tooling (e.g. the Editor.js editor) to convert it to HTML and insert it into the DOM. And it is the tools that perform this conversion that are ultimately responsible for sanitizing the HTML before inserting it into the DOM.

Of course, I know that the back-end can also sanitize HTML. Security in depth. But it comes with a cost which in this case seems to be too great. Consider the following:

• AFAIK Editor.js already sanitizes before display (let me know if this is wrong).
• In order to sanitize an Editor.js document, the server needs to know the spec of all possible blocks and either remove, reject or ignore (don't sanitize) unknown blocks. With an ecosystem consisting of many microservices that can accept Editor.js format, this seems like it would be heavy on maintenance. All APIs would need to be updated whenever the front-end wants to use new blocks, or even whenever a block has been updated with new capabilities that change the format – even in an otherwise backwards-compatible way, e.g. adding a field. The new field would not be checked by the back-end, and would also probably be removed, at least in strongly typed languages (when serializing/deserializing to known types with known properties, even just a round-trip can destroy unexpected data).
• The point above may also be valid for inline blocks, since HTML tags used by new inline tools may need to be added to the sanitation whitelist.

In light of the above, it seems to me that not sanitizing Editor.js documents in the back-end is an acceptable risk.

Please let me know if you agree or disagree.

[SKevo18]

Editor.js sanitizes the HTML client-side. This is not very good, as you should never trust client. Skilled users can manipulate this and send you any data they want (eg.: removing the sanitization part client-side, and sending you raw HTML - security risk).

Always make sure to double-check it in the backend and sanitize it, if it isn't (maybe a check to see if it contains some HTML characters, like <, >? Also, leave out safe tags: <b>, <i>, etc.).

[cmeeren]

Editor.js sanitizes the HTML client-side. This is not very good, as you should never trust client. Skilled users can manipulate this and send you any data they want (eg.: removing the sanitization part client-side, and sending you raw HTML - security risk).

Yes, but my understanding is that Editor.js sanitizes on display. Is this correct? If it is, then e.g. a <script> tag being returned doesn't matter because it will be sanitized before inserting into the user's DOM.

Also, see the second bullet point in the OP.

[photonstorm]

If you have no intention of storing whatever Editor.js creates server-side, then I agree with your hypothesis.

Otherwise, surely the issue here is the complete lack of protection from incoming attack vectors, not client-side rendering ones?

[SKevo18]

Client side is fine, who would want to hack themselves - it's pointless to hack yourself, eg: render script without ever showing it to other users. My point was looking at server-side implementation.

Example:
You are running a blog page that allows users to post blog comments, you use Editor.js.
An attacker makes raw API request with Editor.js unsanitized data to the blog comment POST route. That comment is then saved into database. However, it contains dangerous <script>, collecting user information.

When the comment is rendered along with the script, everytime you load the page with that comment, you are exposed to a risk.

So, as for the original question "Is it OK for an API to not sanitize Editor.js documents?", the answer is - no, it's not okay.

I agree with all that you said, I wrote this for whoever else might be looking at this - please, always also sanitize server-side, and don't trust clients.

[photonstorm]

Yup, agree 100% @CWKevo - your example is showing a client-side vector, but wow, the sheer thought of saving un-sanitized data anywhere server-side chills me to the bone. The potential for having your server compromised is off the charts.

[cmeeren]

When the comment is rendered along with the script, everytime you load the page with that comment, you are exposed to a risk.

Surely this is not the case if Editor.js does indeed sanitize on render? I.e., if Editor.js either removes the <script> tag or HTML-encodes it (<script>)?

The potential for having your server compromised is off the charts.

The server? How so? Here's what the server is doing (I assume this goes for most servers accepting and returning Editor.js documents):

• Storing the data (using a prepared SQL statement of course, no chance for SQL injection)
• Reading the data from DB and returning it to the API client
• Parsing the blocks, e.g. to extract plain-text for SQL a full-text search index
• Possibly parsing the document for other purposes

I don't see how any of this that can possibly put the server at risk. Can you give an example of how the server can be compromised by a (deliberately and maliciously crafted) Editor.js document?

[neSpecc]

1. Editor.js does not sanitize data on rendering — we trust the backend. We do sanitize on saving and pasting.

2. The generated JSON may be rendered by any other application besides editor.js, for example by mobile applications, RSS readers, own web clients, and so on. And this JSON should be sanitized.

3. We recommend sanitizing the data got from the editor.js on your backend side. Because only you know what kind of blocks you support, which Inline Tools you use, and so on. Here is an example of our backend implementation for PHP. It contains the universal implementation of validation and sanitizing for any set of tools — developers should fill only their own config

4. I think that not all of the microservices should do sanitizing — only those that accept "taint" data by the public API. All the internal microservices should work through the secure private API with the clean trusted data.

[cmeeren]

1. Editor.js does not sanitize data on rendering — we trust the backend. We do sanitize on saving and pasting.

Thanks, this is exactly the kind of clarification I needed.

4. I think that not all of the microservices should do sanitizing — only those that accept "taint" data by the public API. All the internal microservices should work through the secure private API with the clean trusted data.

Yes, but in our case most services do accept Editor.js user input. (We have mostly public API microservices, few pure back-end ones).