经过一番挖掘，我发现了一些关于这个主题的近期活动的证据：XML 加密 1.1 中变化的功能解释（W3C 工作组说明 2013 年 4 月 11 日）。XML Encryption 1.1 中有很多变化，其中包括：

• 添加了密钥派生
• 添加了椭圆曲线 Diffie-Hellman 密钥协议
• 添加的算法
• 改变的算法

与您的问题最相关的是安全注意事项的更改：

添加了有关选择密文攻击的安全注意事项信息，包括对加密数据和加密密钥的攻击。提供有关 CBC 块加密漏洞和 Bleichenbacher 攻击的具体说明。

您正在阅读的文章是关于利用 CBC 模式中的一个弱点来链接不同的密文块。虽然它看起来是真实的，但它适用于XML 加密 1.1 之前的加密方案：

“我们能够通过将修改后的密文发送到服务器，通过从收到的错误消息中收集信息来解密数据。” 该攻击针对 XML 加密的流行开源实现以及响应负责任披露的公司的实现进行了测试——在所有情况下，结果都是相同的：攻击有效，但 XML 加密不安全。

虽然我不认为这是夸大其词，但也没有让我感到惊讶（例如，请参阅这个问题的答案How less secure is an encryption is an encrypted if we know about the original data? and Wiki on Adaptive selected- ciphertext attack），需要再次提及的是，它适用于 XML Encryption 1.0 中可用的 CBC 加密模式，该模式由不同的 W3C 工作组处理（XML Encryption WG最后一次活跃于 2008 年）。

现在，这项工作已转移到XML 安全工作组，其婴儿是 XML 加密 1.1，作为对本文中描述的此类攻击的直接回答。事实上，XML 安全工作组甚至在 XML 加密 1.1 文档中直接提到了这些针对 XML 加密 1.0 的攻击。

附录：在阅读一些不相关的密码学文章时，我偶然发现了Matthew Green的博客文章，关于本周的攻击：XML 加密，可追溯到 2011 年 10 月。Matthew Green 是约翰霍普金斯大学的密码学家和研究教授，并撰写有关密码学和相关主题的最精彩的文章。他对这种针对 XML 加密的攻击的全部内容的解释是我读过的最好的解释，当然也是推荐给有兴趣了解更多有关它们的任何人的读物。这是一个简短的摘录：

停止使用未经身份验证的 CBC 模式。停止使用 2003 年之前设计的、未经仔细分析和最近更新的任何加密标准。完全停止使用任何未经身份验证的加密。如果可以的话，用 TLS（最新版本！）包装你的 SOAP 连接。

^{资料来源：本周攻击：XML 加密，Matthew Green}

我认为如果我对此答案添加评论（包括当前状态）会有所帮助。

自适应选择密文攻击：
应用于 XML 加密的攻击是自适应选择密文攻击。在自适应选择密文攻击场景中，攻击者获取原始密文，对其进行修改，然后发送到服务器。然后他评估服务器响应，这使他能够确定底层明文是否有效。他重复了几次，这使他能够解密整个消息。

例如，这些攻击适用于 CBC 方案（密码块链接操作模式），该方案仍由 XML 加密或许多其他标准标准化。CBC（AES-CBC 或 3DES-CBC）允许在不知道加密密钥的情况下修改密文中的明文。更具体地说，攻击者能够翻转明文中的特定位（我不详述，请阅读第一个答案中提到的 Matt Green 的论文或博文）。如果明文中的某些位被翻转，攻击者就会产生一条消息，XML 解析器无法处理该消息。其他位产生有效的明文。

攻击先决条件： 执行攻击有两个先决条件。首先，攻击者必须能够修改密文并强制服务器处理它们。其次，攻击者必须知道解密后的修改密文是否有效。这通常是可能的，因为如果修改后的密文有效，服务器会用不同的错误消息响应，如果它无效，则用不同的消息响应（还有其他方法可以区分有效或无效消息，例如通过测量响应时间）。

好的，但是 XML 签名应该确保完整性…… 是的，我们有 XML 签名标准，它允许保护 XML 消息的完整性。这在理论上可以减轻攻击，因为可以对密文进行签名。这可以防止密文修改（第一次攻击的先决条件）。

但是，在所有经过测试的框架中，即使应用了 XML 签名，也有可能应用这种攻击。简而言之，典型的 XML 签名仅保护 XML 消息的一部分。我们能够将修改后的密文放入未签名的部分中。即使它们没有签名，框架也会对它们进行处理和解密。

XML 加密标准没有考虑这一点，现在在最新版本中得到解决，包括安全加密方案 AES-GCM：http ://www.w3.org/TR/xmlenc-core1/

我们分析的框架： 我们分析了一些框架，发现它们容易受到攻击。例如 Apache Axis2、JBossWS、Apache CXF 或一些 SAML 框架。即使使用了 XML 签名，这些攻击仍然有效。

对策： 如第一个答案所述，最新标准中列出了几种对策。如果您设计或使用 XML 安全性，您的服务器应仔细检查密文是否已签名。如果消息包含未签名的密文，则应拒绝该消息。这就是它现在在 Apache CXF 中的实现方式。另一种可能性是使用 AES-GCM ......

有关更多信息，您可以查看我的论文，其中总结了所有攻击（包括对 RSA PKCS#1 v1.5 的攻击）并提供了几种对策：http ://www.nds.rub.de/research/publications /xmlinsecurity/

当前状态： 通过提出的对策，可以部署一个安全的系统来抵御自适应选择密文攻击。我们进行了几次渗透测试，我们看到了许多系统，我们无法应用这些攻击。

我认为 XML 加密（连同 XML 签名）是一个很好的标准，支持如此多的机密性场景。但是你必须注意你如何配置你的系统（我不确定框架默认是安全的）。

更新

我们为我们的 WS-Attacker 框架发布了一个插件，以使用 XML 加密测试 Web 服务中的漏洞：http ://web-in-security.blogspot.de/2015/05/how-to-attack-xml-encryption-in -ibm.html

我们介绍了我们的新论文：如何自动破解 XML 加密：https ://www.nds.rub.de/research/publications/how-to-break-xml-encryption-automatically/ 在那里，我们还分析了 WCF 框架.