JMAP HTML email security considerations

Hi all,

I'm the primary editor for JMAP[1], 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. Any comments or feedback much
appreciated, either via email on/off list or in the GitHub pull
request[2].
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[3] 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.

Links:

  1. https://datatracker.ietf.org/wg/jmap/about/
  2. https://github.com/jmapio/jmap/pull/197
  3. https://www.w3.org/TR/CSP3/