Content text being rendered as HTML

[rgaudin]

If you look at this comment on Stack Overfow, you'll notice it mentions BufReader<Input> in a <code /> block (used backtick on SO).

Now look at the corresponding entry on browse (question ID: 70462689, Title: Rust: Wrapping a BufRead in Mutex while still implementing BufRead), you'll see that this comment has its <Input> been replaced by an HTMLInputElement.

It seems the <code /> block was ignored in the comment text and whatever the content being, it is considered safe (in Jinja's sense).

Safe to assume this could be exploited by malicious ZIM content, thus the label.

---

Brought to our attention by https://www.ncsc.nl/

[benoit74]

We need to reproduce / wait for latest ZIM. This might have been an upstream issue (in SE dumps) where data was incorrectly rendered / escaped. At least it rings me some bells, so there is a possibility it is already fixed.

From a more general perspective, I'm quite sure there could be some security holes, but I do not have the expertise to easily spot them, and I'm not confident they can be easily detected (we somehow have to trust the code provided in the dumps)

[rgaudin]

It seems we are indeed already getting HTML from SO.

https://github.com/openzim/sotoki/blob/main/src/sotoki/renderer.py#L103-L104

I kinda recall comment were handled different. Worth checking with last dump indeed.

[benoit74]

Thank you for reporting, it is anyway a good thing to better document this and check if we can enhance something.

[its-me-maady]

Hi @rgaudin, I've traced the issue further from your pointer to renderer.py:103-104.
There are actually two places where escaping is disabled, and they compound each other:

mistune.create_markdown(escape=False) in utils/html.py — angle brackets in comment text pass through as raw HTML tags after markdown processing
autoescape=False on the Jinja2 Environment in renderer.py — no template-level safety net either

The root cause is that rewrite() was designed for post bodies (which arrive as pre-rendered HTML from the dump and should not be double-escaped), but it's being reused for comment Text which is plain text with markdown — a different format that needs HTML escaping before markdown processing.
So when a comment contains BufReader<Input>, mistune converts the backticks to BufReader but leaves as a raw tag, which the browser then treats as an HTMLInputElement.
Proposed fix: a dedicated escape_comment_text() function that calls html.escape() before passing to mistune, and a rewrote_comment Jinja filter that uses it — keeping post body rendering completely unchanged.
Happy to open a PR if this diagnosis looks correct to you.
(Context: I'm the author of PR #396 and am considering a GSoC proposal around sotoki. I also noticed issue #138 on the overview repo — happy to discuss either direction, whichever you'd prefer to mentor.)

[rgaudin]

Happy to open a PR if this diagnosis looks correct to you.

Please do

[its-me-maady]

PR is open: #397. Happy to address any feedback.