Potential XSS Attack by using @html

[MoinJulian]

Using @html could expose the code to a XSS attack. All data rendered on the client that can contain raw html should be serialized before being send to the client.

I will start working on this tomorrow

[ScriptRaccoon]

Using @html could expose the code to a XSS attack.

This is true if the html is coming from user input. Here, it's not. I have looked into the occurances of @html in the repository, and all of them come from data saved in the repository itself (mainly, in .sql files, rendered via katex as html).

Typical example: /src/routes/functor-implication/[id]/+page.svelte has

<p>
    <strong>Reason:</strong>
    {@html data.implication.reason}
</p>

The variable data.implication.reason comes from the database table category_implications. No user can edit this data unless

1. ... they submit a PR, which I review of course
2. ... they get access to the database (at which point we have a bigger problem than just XSS)

But since most pages are prerendered (only exception: search + comparison), even database access will not allow an XSS attack there. The page src/routes/category-comparison/[...ids]/+page.svelte is not prerendered and uses {@html category.notation}, so this is the only place where an attacker with access to the database can perform an XSS attack.

There is only one place where users can submit data, via the suggestion form (#111), and here I didn't use @html, namely in src/routes/admin/submissions/+page.svelte.

Before working on this, I suggest to first show that there is a real attack scneario.

[ScriptRaccoon]

I tried to add a script tag in the sql files and let it render with @html. But it didn't work.

For example, this in N.sql

(
	'N',
	'small',
	TRUE,
	'<script>console.log(''hi'');</script> ...'
),

had no effect. No log is seen on the server or the client.

I logged the value to be rendered, the script-tag was definitely still in the variable that should be rendered, but for some reason it does not happen. So for a moment I thought that Svelte has changed this behavior and automatically sanitizes the html, but no, that's not true either, and the documentation also doesn't say otherwise.

I also tried escaping with

<script>console.log(''hi'');<\/script>

but still no result.

If there is no attack scenario, I will close this issue.