I am designing a site for sharing technical blogs and I’d love to include Typst as a markup language. However, I have some questions regarding security. In particular, I’m concerned that:
The HTML export feature seems to allow custom embedding of arbitrary HTML, which could be trivially used to execute XSS or other JavaScript-based attacks. Is there any way to disable dangerous HTML features?
Typst seems to offer the ability to execute custom WASM through packages. I see a brief note: “For security reasons, plugins run in isolation from your system.” The 0.14.2 release notes mention a memory vulnerability that was patched. At this point in the project, how secure is the compiler against adversarial plugins (or other adversarial usage)?
…we take the safety of just compiling a Typst file very seriously. Features that would compromise safety (like writing files, shell escape, even reading files outside of the working/project directory, etc.) won’t be accepted into the Typst compiler.
—Laurenz Mädje, 2023-10-22
About wasm plugsins, do you allows users to upload *.wasm to your website, or only allow loading plugins in packages from Typst Universe? If it is the latter, since packages are reviewed before publishing, I don’t think there is too much risk.
I have a robot on my server that receives typst code and replies with compiled PNGs (on QQ, a social media platform). I encountered two risks when developing it:
I accidentally set the project root to ~, making it possible to read any file under ~, including ~/.ssh/*.
(I download the typst executable to the host system, but mount it into a docker container to run. Therefore, there was nothing leaked.)
I set a too large PPI (pixels per inch) for PNG export, and it filled up the server bandwidth.
This should tell you what the risks of compiling typst are.
That’s great, thank you! I searched through the GitHub issues but somehow missed that particular one.
As for the first point, I don’t expect that the feature exists, but I would like to confirm that. I should be able to whitelist HTML tags and attributes using a parser/sanitizer (like Ammonia for Rust), but I won’t do that unless I have to—I would like to give authors as much freedom as possible. A sanitizer could also require some experimentation if Typst renders HTML using any unusual tags.
No, there is currently no such option. Apparently from my understanding the Typst team is considering to add something like that. In the context of raw SVG embeding Laurenz wrote in #7040 (comment):
[…] There will likely be different security levels for HTML export.
About the second point about plugins, they are strictly sandboxed and can only receive and return data via bytes from the Typst document.
For security reasons, plugins run in isolation from your system. This means that printing, reading files, or similar things are not supported.
—plugin documentation
To add to @Y.D.X list, third “risk” would be symlinks, Typst can follow them and read files outside of the project root.
That’s awesome! Happy to hear it’s on the roadmap. I can start with sanitization and adopt that feature once it’s available. And thank you for clarifying that point about plugins—that documentation quote is a bit ambiguous.
symlinks are not a risk in my case, but that is a good thing to document here for future readers.
Also to future readers, HTML sanitization libraries exist in most languages. Here are a couple more I found that at first glance appear reasonably trustworthy:
Maybe one further thing to add regarding symlinks: since Typst can’t write files other than the output file, malicious Typst code can’t create a symlink. The other way to get a symlink, via downloading a malicious package, is handled:
when we untar a package bundle we should also skip symlinks in the bundle. But I think we have already made them, just to confirm it.
We do. At least I’m fairly sure I checked that at the time.