Reading the article, I kept thinking: "could you defeat this with an iframe?", and indeed:
> One of the best methods to protect against these attacks is strict isolation. If you isolate the email message using sandboxed iframes you restrict the ability to break out of trusted boundaries. If you are not using sandboxed iframes, always be careful when allowing custom attributes and check for HTML/CSS gadgets. Use a strict allow list of characters when validating keywords and names to avoid mutation when using the CSSOM.
iframes should be the first layer of any defense-in-depth against user-submitted content.
Reading the article, I kept thinking: "could you defeat this with an iframe?", and indeed:
> One of the best methods to protect against these attacks is strict isolation. If you isolate the email message using sandboxed iframes you restrict the ability to break out of trusted boundaries. If you are not using sandboxed iframes, always be careful when allowing custom attributes and check for HTML/CSS gadgets. Use a strict allow list of characters when validating keywords and names to avoid mutation when using the CSSOM.
iframes should be the first layer of any defense-in-depth against user-submitted content.
Would a hard isolation model for HTML email be a better long-term solution, or is that impractical for reasons I’m missing?
Allowing anything other than plain text in email bodies was a terrible mistake.
> In this section I targeted Fastmail, ProtonMail, Gmail, Cowork and Slack.
Oh that's all, is it?
> This page requires JavaScript for an enhanced user experience.
Yeah no shit.
You're certainly welcome to browse the internet without JavaScript.
But when most of the articles submitted here don't work without JavaScript, this comment seems really irrelevant.