Re: JMAP HTML email security considerations

On Apr 8, 2018, at 8:51 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

> I'm the primary editor for JMAP, the new email sync protocol being standardised at the IETF. I'm currently adding the security considerations for rendering HTML email, and Mark Nottingham suggested I run it by this group for review.

All of the security problems you describe (below) with HTML in email have long been known. Back in the old days where was a small group of people who resisted HTML in email and offered an alternative: text/enriched defined in https://tools.ietf.org/html/rfc1896 (not to be confused with rich text format).

If something like this were to be revived today, it might make sense to start with a something like Markdown as the creation syntax and then render directly by parsing the Markdown (instead of Markdown to HTML.) The advantage of Markdown is that it is readable and writable as text/plain. Remote content would have to be limited. So there would need to be a mechanism for displaying local images.

Another alternative would be to strictly enforce use of HTML v3.2 with CSS1 (and restricting remote content). This would have richer styling than text/enriched. My suggestion of HTML 3.2 and CSS1 is not based on careful evaluation, but involve some off of the top of my head guesswork. My intent is that it be something that is sufficiently conservative to be very safe to parse with a context-free parser (or near enough).

Anyway, I wish you well and hope that you have better luck with this than us advocates of text/enriched (over HTML) in email did 20 years ago.

Cheers,

Jeffrey Goldberg
1Password



> Any comments or feedback much appreciated, either via email on/off list or in the GitHub pull request.
> 
> Cheers,
> Neil.
> 
> ------
> HTML message bodies provide richer formatting for emails but present a number of security challenges especially when embedded in a webmail context in combination with interface HTML. Clients that render HTML email should make careful consideration of the potential risks, including:
> 
>  • If JavaScript is allowed to execute it can rewrite email to change its content on subsequent opening, allowing users to be mislead. In webmail systems it can access and exfiltrate all user content accessible via the browser, including all other emails and potentially contacts, calendar events, settings, and login credentials. It can also rewrite the interface to undetectably phish passwords.
>  • HTML documents may load content directly from the internet, rather than just referencing attached resources. For example you may have an <img> tag with an external src attribute. This may leak to the sender when a message is opened, as well as the IP address of the recipient. Cookies may also be sent and set by the server, allowing tracking between different emails and even website visits and advertising profiles.
>  • In webmail systems, CSS can break the layout or create phishing vulnerabilities. For example, the use of position:fixed can allow an email to draw content outside of its normal bounds, potentially clickjacking a real interface element.
>  • If not inside a separate frame in a webmail context, any styles defined in CSS rules will apply to interface elements as well if the selector matches, allowing the interace to be modified. Similarly, any interface styles that match elements in the email will alter their appearance, potentially breaking the layout of the email.
>  • The link text in HTML has no neccessary correlation with the actual target of the link, which can be used to make phishing attacks more convincing.
>  • Links opened from an email may leak private info in the Referer header sent by default in most systems.
> Sanitizing HTML to mitigate these issues is tricky. Using a well-tested library with a carefully vetted whitelist-only approach is the safest way to avoid vulnerabilities. New features with unexpected security characteristics may be added to HTML rendering engines in the future; a blacklist approach is likely to result in security issues.
> 
> A defence in depth approach can help to mitigate the risks of HTML email. Webmail systems are strongly encouraged to use a strong Content Security Policy as a second line of defence to block malicious content should it manage to evade the filter.
> 
> Subtle differences in parsing of HTML can introduce security flaws: to filter with 100% accurately you need to use the same parser when sanitizing that the HTML rendering engine will use.
> 
> As highly complex software components, HTML rendering engines increase the attack surface of a client considerably, especially when being used to process untrusted, potentially malicious content. Serious bugs have been found in image decoders, JavaScript engines and HTML parsers in the past, which could lead to full system compromise. Clients using an engine should ensure they get the latest version and continue to incorporate any security patches released by the vendor.
>