Fwd: JMAP HTML email security considerations

This was sent to the webappsec group, but I think they have said they  
would rather not do security review. Whereas this group is chartered to do  
that...

------- Forwarded message -------
From: "Neil Jenkins" <neilj@fastmailteam.com>
To: public-webappsec@w3.org
Cc:
Subject: JMAP HTML email security considerations
Date: Mon, 09 Apr 2018 03:51:05 +0200

Hi all,
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. 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.
-- 
Chaals: Charles (McCathie) Nevile find more at https://yandex.com
Using Opera's long-abandoned mail client: http://www.opera.com/mail/
Is there really still nothing better?