Notifications: use sanitize-html for cleaning header/body content

[agjohnson]

This was a library that was brought in for displaying ANSI color codes in the build detail command output. It is currently unused, but was loaded async previously. It seems we could use this for notifications as well, making it a standard part of our bundled JS. Or, alternatively, load it async when there are notifications.

We only need to support some minor elements in notification body/header, mostly formatting and links.

• For background on this feature on the build detail page Build: support terminal escape/control codes and color codes #71

ext-theme/src/js/build/detail.js

Lines 153 to 179 in bd12f15

	return Promise.all([
	import(
	/* webpackChunkName: 'ansi_up' */
	"ansi_up"
	).then(({ default: AnsiUp }) => {
	return AnsiUp;
	}),
	import(
	/* webpackChunkName: 'sanitize-html' */
	"sanitize-html"
	).then(({ default: sanitize_html }) => {
	return sanitize_html;
	}),
	]).then((imports) => {
	let AnsiUp, sanitize_html;
	[AnsiUp, sanitize_html] = imports;
	// Build output lines
	let ansi_up = new AnsiUp();
	ansi_up.use_classes = true;
	output = ansi_up.ansi_to_html(output);
	output = sanitize_html(output, {
	allowedTags: ["span"],
	allowedAttributes: { span: ["class"] },
	});
	return output;
	});

[stsewd]

Another popular option is DOMPurify https://github.com/cure53/DOMPurify

[agjohnson]

@stsewd What sort of scenario would this help cover? I know we talked about cleaning the notificaiton HTML before DOM insertion, but if the notification HTML is safe inside our API, is there any case where this wouldn't be safe as we are injecting it into the DOM?

[stsewd]

As long as our notifications don't include user content withotu escaping, we shuold be good.

[agjohnson]

@humitos are we consistently escaping user input in notifications through the API? I couldn't actually find where we were sanitizing message body/header content. I thought this happened at the model or API level