深入剖析 XXE 与 Billion Laughs 攻击：原理、实战与防御

2026-02-03 23:08:27 0条评论 2次阅读 0人点赞

引言：当我们面对 XML 数据时的隐忧

作为一名开发者，我们经常在处理数据交换时遇到 XML 格式。虽然 JSON 如今大行其道，但在许多遗留系统、企业级 API 以及文件上传功能中，XML 依然扮演着重要角色。然而，你是否想过，当你简单地解析一段看似普通的 XML 数据时，可能正将服务器的文件系统拱手让人？

在本文中，我们将深入探讨 Web 安全领域中两个至关重要但常被忽视的威胁：XML 外部实体（XXE）注入攻击和“Billion Laughs”（十亿次笑）攻击。我们将从攻击原理入手，通过代码演示漏洞是如何产生的，并最终学习如何构建坚固的防御体系。

什么是 XXE 攻击？

XXE（XML External Entity）攻击是一种针对应用程序解析 XML 数据方式的攻击手段。当应用程序允许用户输入 XML 数据，并且解析器配置不当时，攻击者可以利用 XML 的“实体”功能，读取服务器上的本地文件、探测内网端口，甚至引发拒绝服务攻击。

简单来说，如果我们接收到的 XML 数据中包含了恶意外部实体定义，而解析器忠实地执行了这些定义，那么我们的系统就可能面临严重的安全风险。

XXE 攻击的主要类型

为了有效地防御，我们必须了解对手的武器库。XXE 攻击通常可以分为以下几种主要类型，让我们逐一剖析。

#### 1. 文件检索型 XXE

这是最直接的一种利用方式。顾名思义，攻击者的目的是窃取数据。如果我们的系统中存在易受攻击的端点，攻击者可以通过构建恶意的 XML 实体，将服务器本地的敏感文件（如 /etc/passwd、配置文件等）窃取出来。

场景模拟：假设我们有一个功能允许用户上传 XML 格式的个人资料。攻击者可以构造一个包含外部实体的 XML，该实体指向服务器的文件系统路径。当解析器处理该实体时，它会读取文件内容并将其嵌入到响应中，从而导致数据泄露。

#### 2. 盲注 XXE (Blind XXE)

有时候，即使我们受到了攻击，应用也不会直接返回文件内容给我们。这就是所谓的“盲 XXE”。在这种情况下，目标系统可能不会在响应中回显我们定义的实体数据，但这并不意味着系统是安全的。

探测手段：

错误注入：攻击者通常通过发送格式错误的 XML（如过长的标签、错误的数据类型）来触发解析器的错误响应。通过分析错误信息，我们可以判断解析器是否处理了外部实体。
带外数据泄露：这是盲注 XXE 的核心利用方式。我们可以定义一个外部实体，指向攻击者控制的服务器（例如 http://attacker.com/log）。当服务器解析该实体时，它会向我们的服务器发起 HTTP 请求。通过这种方式，即使目标应用不返回数据，我们也能在自己的服务器日志中看到“受害者”的访问记录，从而确认漏洞存在。

#### 3. XXE 导致的服务器端请求伪造 (XXE to SSRF)

SSRF（服务器端请求伪造）是 XXE 攻击中极具危害性的一种变体。即使系统没有回显本地文件的内容，我们仍然可以利用它来攻击内部网络。

原理：通过在 XML 实体中指定目标公司的内网 IP 地址（例如 http://192.168.1.1/admin），我们可以强迫应用程序的服务器代替我们去访问这些内部端点。由于请求来自服务器内部，它通常会绕过防火墙，访问攻击者无法从外部触用的敏感服务。

XML 解析基础与漏洞成因

为了理解漏洞，我们需要先看看正常的 XML 解析是如何工作的。XML 是一种强大的标记语言，它允许定义“实体”。实体类似于变量或宏，可以在文档中重复使用。

#### 正常的 XML 结构

让我们看一个标准的 XML 数据交换示例。假设我们有一个接受用户信息的接口，提交的数据如下：




  
    Siva
    24
    Lead
  
  
    Subbu
    25
    Developer

在这个例子中，数据是封闭且安全的。然而，XML 的强大之处（也是危险之处）在于它支持 DTD（文档类型定义），而 DTD 允许定义外部实体。

#### 外部实体定义

看下面这段代码片段，它定义了一个名为 test 的实体，该实体引用了一个外部 URL：


<!DOCTYPE data [
    
    
]>

    &test;

如果不加限制地解析这段代码，解析器会尝试下载 INLINECODE93d9f0e7 上的内容并将其填充到 INLINECODE111e2511 标签中。这就是 XXE 漏洞的源头。

实战演练：编写易受攻击的解析器

为了更好地理解，让我们编写一段 Java 代码来模拟 XML 解析过程。在 Java 中，DocumentBuilderFactory 是常用的解析工具。如果不进行安全配置，它默认是支持外部实体的。

环境准备：

这段代码演示了一个典型的解析逻辑。它读取文件并将其转换为可查询的对象。

// 示例 3：易受 XXE 攻击的 Java XML 解析器
import java.io.File;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.NodeList;
import org.w3c.dom.Node;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

public class InsecureXMLParser {

    public static void main(String[] args) {
        try {
            // 假设这是用户上传的 XML 文件路径
            File file = new File("/tmp/user_input.xml");

            // 获取 DocumentBuilderFactory 实例
            DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
            
            // 【关键点】这里创建 DocumentBuilder，默认情况下它是支持外部实体的！
            DocumentBuilder db = dbFactory.newDocumentBuilder();

            // 解析 XML 文件
            Document doc = db.parse(file);

            // 规范化 XML 文档结构
            doc.getDocumentElement().normalize();

            // 提取数据
            NodeList nodeList = doc.getElementsByTagName("profile");
            
            System.out.println("解析到的用户数据数量: " + nodeList.getLength());

            for (int ind = 0; ind < nodeList.getLength(); ind++) {
                Node node = nodeList.item(ind);
                if (Node.ELEMENT_NODE == node.getNodeType()) {
                    Element nodeElement = (Element) node;
                    // 打印用户名
                    System.out.println("Name: " 
                        + nodeElement.getElementsByTagName("name").item(0).getTextContent());
                }
            }
        } catch (Exception e) {
            System.err.println("解析 XML 时发生错误: " + e.getMessage());
            e.printStackTrace();
        }
    }
}

代码解读：在这段代码中，我们并没有显式地禁用外部实体。因此，如果传入的 XML 文件包含了恶意实体，db.parse(file) 这一行就会忠实地去访问攻击者指定的资源。

攻击演示：利用 XXE 读取本地文件

现在，让我们站在攻击者的角度，利用上述的解析器漏洞来窃取数据。我们可以构造一个包含恶意 DTD 定义的 XML 文件。

攻击载荷：



<!DOCTYPE profiles [
    
    
    
]>

  
      
      &xxe;
      test

攻击流程解析：

上传：攻击者将上述代码保存为 XML 文件并上传。
解析：我们的 Java 程序接收到文件，开始解析。
实体替换：解析器看到 INLINECODE0db6ae9b，根据 DTD 定义，它尝试读取 INLINECODEa52d98c3。
泄露：读取到的文件内容被放置在 INLINECODE076f0119 标签中。虽然在某些简单的输出中可能不明显，但如果解析器后续对 INLINECODE15a95ca2 字段进行了输出或日志记录，敏感信息就会泄露。

Billion Laughs 攻击：拒绝服务的艺术

除了数据泄露，XML 实体还可以被用来发起拒绝服务攻击。这就是著名的“Billion Laughs”（十亿次笑）攻击。它的核心思想是利用 XML 解析器的递归引用特性，耗尽服务器的 CPU 或内存资源。

攻击原理：

通过定义多层嵌套的实体引用，极小的 XML 数据（通常不到 1KB）在展开后可以膨胀到 GB 级别，导致服务器崩溃。

恶意载荷示例：



<!DOCTYPE lolz [
  
  
  
  
  
  
  
  
  
  
]>
&lol9;

后果：当解析器尝试展开 &lol9; 时，它会生成数以亿计的“lol”字符串。对于服务器来说，处理这种巨大的数据结构需要消耗极大的计算资源和内存，最终导致服务不可用。

如何构建安全的 XML 解析器

既然我们已经了解了攻击手段，那么作为开发者，我们该如何预防呢？安全的核心在于“禁用”或“限制”危险的 XML 特性。

让我们重构之前的 Java 解析器代码，使其具备抗攻击能力。

// 示例 6：安全的 XML 解析器配置
import java.io.File;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
import org.w3c.dom.Document;
import java.io.InputStream;

public class SecureXMLParser {

    public static void main(String[] args) {
        try {
            File file = new File("/tmp/user_input.xml");
            InputStream is = new java.io.FileInputStream(file);
            
            // 获取 DocumentBuilderFactory
            DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();

            // 【关键安全配置 1】：禁用外部实体（DTD）
            // 这一行代码是防御 XXE 的核心，它会禁止解析外部实体
            dbFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
            
            // 【关键安全配置 2】：如果必须支持 DTD，至少要禁止外部实体
            // 注意：如果上面的 disallow-doctype-decl 为 true，下面这行可能会抛出异常
            // dbFactory.setFeature("http://xml.org/sax/features/external-general-entities", false);
            // dbFactory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

            // 【关键安全配置 3】：防止 Billion Laughs 攻击
            // 限制实体扩展的次数，防止指数级膨胀
            dbFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

            DocumentBuilder db = dbFactory.newDocumentBuilder();
            Document doc = db.parse(is);

            System.out.println("解析完成，未触发安全风险。");

        } catch (Exception e) {
            System.err.println("安全错误或解析错误: " + e.getMessage());
            e.printStackTrace();
        }
    }
}

关键配置详解

在上述代码中，我们做了一些关键的改变，这些是防御 XXE 的通用原则：

setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)：这是最彻底的防御方法。它完全禁止了 DTD 的使用，从而从根本上消除了实体注入的风险。如果业务逻辑依赖 DTD，这可能会导致功能受限。

限制外部实体：如果业务必须允许 DTD（例如某些旧的标准），那么至少要确保禁用外部实体的解析。这可以通过设置 INLINECODE7aa37c36 和 INLINECODE9ad99f7e 为 false 来实现。

输入验证：不要完全依赖解析器的配置。在代码层面，我们应该验证输入的合法性。例如，检查 XML 头部是否包含 <!DOCTYPE 关键字，如果发现则直接拒绝请求。

常见误区与最佳实践

在修复 XXE 漏洞时，我们经常会遇到一些误区，让我们一起来看看如何避免它们。

误区 1：认为升级库版本就能解决问题

虽然保持依赖库更新是好的，但很多 XXE 漏洞源于配置不当，而非库本身的 Bug。默认情况下，许多主流 XML 解析器（如 Java 的 INLINECODE7346073f，Python 的 INLINECODEe3e49de8）为了兼容性是支持外部实体的。仅仅升级版本而不修改配置，往往无法修复漏洞。

误区 2：只针对 DTD 进行黑名单过滤

试图通过正则表达式过滤 INLINECODE8531e635 或 INLINECODE79051a34 是不可靠的。攻击者可以使用编码、注释混淆等方式绕过过滤。最安全的方式是使用解析器提供的白名单安全特性。

最佳实践建议：

最小权限原则：应用程序运行在的用户权限应尽可能低，这样即使通过 XXE 读取了文件，也只能读取到非敏感的系统文件。
使用更安全的数据格式：如果可能，尽量避免使用 XML 处理用户输入。JSON 通常是更安全、更简洁的选择。
网络隔离：确保应用服务器无法访问敏感的内网 IP（如数据库、SSRF 目标），但这属于纵深防御措施，不能替代 XML 解析器的安全配置。

性能优化与错误处理

除了安全，正确的 XML 解析还需要考虑性能和健壮性。XXE 攻击不仅是数据泄露，更是 DoS 的温床。我们已经在代码中展示了如何通过限制实体扩展来防止 Billion Laughs 攻击，这不仅是为了安全，也是为了保证服务的高可用性。

此外，在处理异常时，切忌将原始的 XML 解析错误直接抛给用户。详细的错误信息可能包含服务器内部路径或 XML 结构细节，这些信息会帮助攻击者调试他们的攻击脚本。我们应该捕获所有 Throwable，记录具体的错误堆栈到服务器日志中，并向前端返回一个通用的“数据格式错误”提示。

总结

通过这篇文章，我们深入探讨了 XXE 攻击和 Billion Laughs 攻击的原理。从简单的实体定义到复杂的内网探测，我们看到了 XML 解析器在不安全配置下可能带来的巨大风险。

关键在于：永远不要信任用户输入。 无论何时，当你处理 XML 数据时，一定要确保你的解析器禁用了外部实体处理能力，或者严格限制了 DTD 的使用。通过修改代码配置和加强输入验证，我们可以有效地抵御这些威胁，保护我们的应用和数据安全。

希望这些实战经验能帮助你在未来的开发中构建出更安全、更健壮的系统。编码愉快！

投稿给我们	如何建站？
vps是什么？	如何安装宝塔？
如何通过博客赚钱？	便宜wordpress托管方案
免费wordpress主题	这些都是免费方案

豆丁博客