Sanitize output

[dpc]

I'd like to use djot (jotdown) as a format for content formatting in a web application. For that I need to sanitize the rendering, to prevent users from injecting raw html or anything else that I don't want.

Some initial investigation suggests that I wamt to

• intercept RawInline and BlockInline and filter out/sanitize
• intercept Image if I want to prevent linking to arbitrary pictures, possibly Link if I don't want arbitrary links

If there's anything that I should take into consideration, I would appreciate pointing it out. Thank you!

[hellux]

Raw inline should cover custom HTML tags.

Any events may have attributes, though, so e.g. onClick attributes may need to be filtered out.

A safer option might be to run a sanitizer on the full HTML output?

[dpc]

Any events may have attributes, though, so e.g. onClick attributes may need to be filtered out.

Oh, that's possible to do with djot markup?

A safer option might be to run a sanitizer on the full HTML output?

Well, if I have to. I was hoping that just by the virtue of using a markup, it might be easy to avoid injecting random Html.

[hellux]

Oh, that's possible to do with djot markup?

yes, inline and block arguments can be added with braces: https://djot.net/syntax#inline-attributes, https://djot.net/syntax#block-attributes.

Well, if I have to. I was hoping that just by the virtue of using a markup, it might be easy to avoid injecting random Html.

You can definitively manually filter out things, but there's a risk that there is something you have missed, e.g. if some new syntax is added later. A way to try to be sure that you never let anything harmful through might be to run a fuzzer to verify that your full output is always unchanged when run through a sanitizer for any type of djot input.

It might also be worth discussing what type of syntax may be used to generate harmful HTML in the general djot repo, because this should apply to all djot HTML renderers.

[dpc]

I would appreciate if the matter of sanitization output is explicitly considered.

Possibly if I may so suggest, maybe sanitization could be explicitly supported on the API level.

Maybe I'm wrong, but using djot to get both user markup handling and relatively easy sanitization story is very appealing. If I have a web app, and users e.g. post comments, then the parser already does the core job, and all it takes is to filter out relatively few things that users shouldn't need anyway. Doing it on djot level is just faster and leaner, and as you mention the only worry seem to be not missing any syntax addons in the future.

Jotdown could add a method on an Event/Container, like fn is_unsanitary(&self) -> bool 🤣 , so that any new item that allow arbitary html could be stripped-away without downstream users even needing to do anything w.r.t new syntax. Seems like relatively low work at jotdown level to make downstream's life much easier.

[hellux]

I agree that it makes sense to handle the sanitization in jotdown. HTML safety can be considered here when new syntax is added rather than downstream on each upgrade.

This is an HTML-specific problem so I think it can be limited to the HTML renderer. The renderer can already take configuration for indentation, so we could also add a sanitize option that will cause it to filter out any potentially dangerous events or attributes.

It should also be quite straightforward to add another CI fuzzing job that compares the sanitized output from the renderer with the output of an actual HTML sanitizer.

[dpc]

As I got back to work on it, it just occurred to me that having some methods on elements might still be useful.

E.g. I will need to intercept things in Jotdown and do some custom shenigenans anyway, in which case html renderer can just get in a way. I wouldn't mind talking care of stripping / escaping / modifing unsanitary events myself, just would feel better if there was some API-level guarantee that I will not get accidentally rugpulled with a new syntax that I was not aware of. :)

[hellux]

Hmm, a boolean safe/unsafe on an event doesn't tell you how to modify the event to be safe, if it's a boolean the rule must be simple; e.g. the event should be filtered out completely. However, filtering out events arbitrarily may result in invalid html, e.g. if a start container has an onclick attribute, it is unsafe but its corresponding end event doesnt have any attributes so it cannot be considered unsafe, which would yield an end element without any starting element.

[dpc]

Well, yeah, the pairing of the opening and closing event is already something that needs to be handled no matter what - deleting, substituting, etc.

The boolean flag is just the simplest thing, where the main goal is to prevent user from getting accidentally broken by omission, or by upstream adding new events. It does not prevent the user from simply ignoring it for elements they already know how to handle.

It doesn't need to be a bool. Could be eg. some kind of "class" enum, etc. As long as downstream has some clear and robust directions on how to sanitize that prevents security incidents, it's all good.

FWIW. Here is the current rendering code I have: https://github.com/dpc/rostra/blob/8947bd51b6df165be4ea4347d3e69f7fddb96ef8/crates/rostra-web-ui/src/routes/content.rs#L11