XSS in Previews about textpattern

[bloatware]

Thank you for your interest in Textpattern. While we explicitly delegate to admins all content validation, it's difficult to argue here. The preview step might look safer than it is for newcomers.

So, what could we do?

• Implement a strict CSP on the admin side. Actually, some (commented) directives are already in dev config-dist.php file and core works fine, but they could break many old plugins.
• Do the preview on the public side, somehow protecting it from hammering.
• Restrict Textile in previews, or even reserve 'text' mode to the article author.
• Clean up the previewed code, removing html event attributes.
• Something else?

[grozdniyandy]

I think you named everything necessary for the issue to be fixed.

[Bloke]

• Restrict Textile in previews, or even reserve 'text' mode to the article author.
• Clean up the previewed code, removing html event attributes.

How much fallout/blowback would there be if we started here? The point of a preview is to show what the article will look like on the site so if there's additional functionality that is part of the site, it would fail if we stripped off event handling. But the preview itself is limited by nature, so is that a reasonable restriction? It already doesn't render some things (article images?) so maybe this loss isn't so bad.

Although "correct", the strict CSP makes me a little nervous to include by default at this stage - especially without much warning to plugin authors.

[bloatware]

The body/excerpt preview does not parse txp tags anyway, so the rendition can be very different from the public side. IMO, its main interest is to show how the content will look for those not fluent in Textile/HTML. Anyway, we should sandbox the preview window from the rest of the page (risk of id/style/js/etc collisions).

Few things I have tested:

• a sandboxed <iframe sandbox />. Would be ideal, but it's difficult to style properly and is poor UX-wise: on each preview refresh the viewport jumps to the top of the frame. This could be solved if we had access to the frame content via js, but sandbox attribute forbids it. If anyone knows how to autoresize an iframe in pure css, I'm all ears.
• loading the preview content in a <template /> and attaching it as shadow to the preview window. This isolates the preview styles/ids from the rest of the page, but js is still executed.
• purifying the preview content either admin or client-side. Needs some third-party libraries, adding ~200kb to txp. As a bonus admins could be warned if an article includes potentially unsafe content.

Ideas welcome

[grozdniyandy]

Hello Guys, is issue fixed now?

[bloatware]

Hi @grozdniyandy, mostly yes, up to some cosmetic changes. Please test if you can, and thank you for the report. We will mention it in our HISTORY.txt file.

[grozdniyandy]

Thanks for the reply, I tested and it seems to be fixed.

[Bloke]

@bloatware This is mint. The preview window kicks ass now there's the ability to clean up and report the number of infractions. Top stuff, thank you.

[bloatware]

Thanks! Handy, uh? TO DO: new (unsaved) article preview.