Efail: HTML Mails have no Security Concept and are to blame
我最近写下了关于为何我认为废弃的加密标准应对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>提交元素发送表单数据。然而，如果有其他方式发送表单，它们可能仍然有效。事实证明确实有。发送HTML表单也可以通过在任何文本输入元素获得焦点时按“Enter”来启动。聚焦到文本元素可以通过autofocus属性完成。因此，如果你设法诱骗用户按“Enter”，你仍然可以外泄数据。
Thunderbird正在为此场景开发修复，但Enigmail提出了不同的方法。从Enigmail 2.0.5开始，它将拒绝在不寻常的邮件结构中解密邮件。这最初意味着不再可能将HTML部分放在加密部分之前。它只是不会解密它。
绕过3：通过CSS向邮件添加文本
我没有找到任何外泄数据的方法，但我仍然发现了一些不受欢迎的属性。仍然可能将HTML部分放在加密邮件下方，并且该部分可以在<style>标签中包含CSS。这允许一些有限形式的伪装。
一个有趣的可能性是CSS ::before属性。如果只是文本，加密部分将显示在<pre>标签内。通过使用这样的CSS标签，可以在实际消息前显示一个句子：
|
|
这可以用于社会工程尝试，诱骗用户。通过使用背景图像和字体干预，也可以显示任意内容而不是解密的消息。这个技巧在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列出了四个不同的跨站脚本漏洞。）
一个有趣的HTML邮件相关漏洞由Matthew Bryant在2016年发现：他发现自己能够将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邮件没有合理的安