Re: JMAP HTML email security considerations

@Jeffrey That's amazing :D.

@Neil, I like your proposed section — presumably the IETF would prefer you not to include specific code to do this, but we've found DOMPurify [1] and its general approach great for sanitization at Superhuman.

[1]  https://github.com/cure53/DOMPurify 

Sent via Superhuman ( https://sprh.mn/?vip=conrad@superhuman.com )

On Tue, Apr 10, 2018 at 8:52 AM, Jeffrey Goldberg < jeff@agilebits.com > wrote:

> 
> 
> 
> On Apr 8, 2018, at 8:51 PM, Neil Jenkins < neilj@ fastmailteam. com (
> 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 (
> 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.
>> 
>> 
>> 
> 
> 
>