[Vulnerability] Stored XSS via init_editor

[spaceraccoon]

Hi,

There is a stored XSS caused be the conversion of a blog post's contents from the classic editor to the new editor. When clicking the button to switch to the new editor, the code at editor.rs (

Plume/plume-front/src/editor.rs

Lines 383 to 401 in 97cbe7f

	let content_val = get_elt_value("editor-content");
	// And pre-fill the new editor with this values
	let title = init_widget(&ed, "h1", i18n!(CATALOG, "Title"), title_val, true)?;
	let subtitle = init_widget(
	&ed,
	"h2",
	i18n!(CATALOG, "Subtitle, or summary"),
	subtitle_val,
	true,
	)?;
	let content = init_widget(
	&ed,
	"article",
	i18n!(CATALOG, "Write your article here. Markdown is supported."),
	content_val.clone(),
	false,
	)?;
	if !content_val.is_empty() {
	content.set_inner_html(&content_val);

) uses the WebAssembly-JS bridge to run content.set_inner_html(&content_val); using the post's text. If the text contains HTML tags like <img src=x onerror=alert()>, an XSS will occur.

1. In a Plume instance, create a post draft in a blog using the classic editor with the contents <img src=x onerror=alert()>.
2. Autosave.
3. Switch to the new editor. An alert box will pop.

To fix this, you should use content.set_inner_text(&content_val); instead.

• Plume version: 0.7.2
• Operating system:
• Web Browser: Safari

[trinity-1686a]

that vulnerability is currently not triggerable in anyway that's actually useful to an attacker that I can think of, but it will be when #368 gets implemented.

I don't think set_inner_text would do the trick, you are supposed to be able to insert (a safe subset of) html in a blog post. What should be done is the same kind of sanitization that's done when publishing.

[spaceraccoon]

Makes sense, I saw in the UI what seemed like possible shared editing features.

I recommend DOMPurify to do the sanitization since it's the most robust whitelisting solution IMO!