XXE漏洞是什么 如何在解析XML时防范它

来源：AI视频音频作者：比特币程序员头衔：程序员
导读：本期聚焦于比特币程序员创作的《XXE漏洞是什么 如何在解析XML时防范它》，敬请观看详情。XXE漏洞全称XML外部实体注入漏洞，是XML解析过程中常见的安全风险，攻击者可通过构造恶意XML payload读取服务器本地文件、发起内网请求甚至执行远程代码。很多开发者在开发涉及XML数据处理的业务时，容易忽略XML解析器的默认安全配置，导致服务暴露在风险中。本文将先解释XXE漏洞的产生原理，再结合实际开发场景，给出不同编程语言下解析XML时的具体防范方法，帮助开发者快速掌握规避该漏洞的核心技巧。

XXE漏洞是什么 如何在解析XML时防范它

XXE漏洞详解：原理、攻击场景与防御方法，手把手教你安全解析XML

一、什么是XXE漏洞

XXE的全称是XML External Entity Injection，即XML外部实体注入。简单来说，当应用程序解析用户提供的XML数据时，如果没有对XML中的外部实体进行限制，攻击者就可以利用这个特性，让解析器去执行一些非预期的操作。

漏洞产生的根本原因

XML规范中允许定义实体（Entity），实体可以理解为一种变量或宏。其中有一种特殊的实体叫“外部实体”，它可以通过<!ENTITY>声明来引用外部的资源，比如本地的文件、远程的URL等。如果XML解析器默认开启了外部实体解析功能，那么当攻击者传入一段精心构造的XML数据时，解析器就会忠实地去读取那个外部资源，并把内容嵌入到XML中，从而泄露给攻击者。

举个例子，假设你的系统有一个接口，用来接收XML格式的用户反馈。攻击者发送下面这样的XML：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

解析器看到&xxe;时，就会去读取/etc/passwd文件的内容，然后把文件内容替换进去。最终，攻击者通过接口的响应就能拿到服务器上的用户账户信息。

为什么这种漏洞很危险

因为XML解析器通常运行在服务器端，拥有一定的文件读取和网络访问权限。一旦被利用，攻击者不仅可以读取任意文件，还能让服务器向内网发起HTTP请求，扫描内网服务，甚至利用服务器作为跳板攻击其他系统。更严重的是，如果解析器没有超时限制，攻击者还可以构造递归实体，让解析器陷入死循环，耗尽CPU和内存，导致服务瘫痪。

二、常见的XXE攻击场景

1. 读取本地敏感文件

这是最直接的攻击方式。攻击者利用file://协议，指定服务器上的任意文件路径。常见的攻击目标包括：

  • Linux系统：/etc/passwd、/etc/shadow、/etc/hosts、应用配置文件（如数据库密码文件）
  • Windows系统：C:\windows\win.ini、C:\boot.ini、IIS或Tomcat的配置文件

例如，攻击者想读取某个Web应用的数据库配置文件，可能会构造这样的payload：

<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "file:///var/www/html/config/database.php">
]>
<foo>&xxe;</foo>

如果应用直接把解析后的XML内容返回给客户端，那么数据库连接信息就暴露了。

2. 内网服务探测

攻击者可以利用http://协议，让服务器去访问内网中的IP地址和端口。根据返回结果的不同（超时、连接失败、返回特定内容），可以判断内网中哪些主机存活、哪些端口开放。这对于后续的内网渗透非常有帮助。

例如，攻击者想探测内网中是否存在Redis服务（默认端口6379），可以构造：

<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "http://192.168.1.100:6379">
]>
<foo>&xxe;</foo>

如果响应中包含Redis的欢迎信息或错误信息，攻击者就知道这个端口是开放的。

3. SSRF攻击（服务端请求伪造）

SSRF是指攻击者让服务器代替自己去访问第三方资源。在XXE中，攻击者可以让服务器向自己控制的远程服务器发送请求，从而窃取服务器的一些内部信息，比如云服务器的元数据（AWS、阿里云等）。

例如，在阿里云ECS上，可以通过http://100.100.100.200/latest/meta-data/获取实例的临时凭证。攻击者构造：

<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "http://100.100.100.200/latest/meta-data/">
]>
<foo>&xxe;</foo>

如果服务器能访问这个内网地址，攻击者就能拿到云平台的临时访问密钥，进而控制整个云账号。

4. 拒绝服务攻击（DoS）

通过定义嵌套或递归的外部实体，可以让解析器消耗大量资源。经典例子是“Billion Laughs”攻击：

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  ...
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

这个XML会指数级扩展，最终产生巨大的文本量，导致内存溢出或CPU飙升。虽然现代解析器大多有限制，但依然是一种潜在威胁。

三、如何有效防范XXE漏洞

防范XXE的核心思想很简单：禁用不需要的外部实体解析功能。具体来说，就是要关闭XML解析器对外部实体（包括外部通用实体和外部参数实体）的支持，同时禁止DTD（文档类型定义）的加载。

通用安全原则

在开始看代码之前，先记住几条原则：

  1. 能不解析XML就别解析。如果业务允许，优先使用JSON、Protobuf等更安全的格式，从源头上消除XXE风险。
  2. 如果必须解析XML，务必禁用外部实体。大多数主流XML解析库都提供了相应的配置选项。
  3. 对输入的XML进行白名单校验。比如检查是否包含<!DOCTYPE、<!ENTITY等关键字，如果有则直接拒绝。
  4. 最小权限原则。限制XML解析进程的文件读取权限和网络访问权限，即使出现漏洞，也能降低损失。
  5. 保持库版本更新。较新的XML解析库往往默认更安全，减少了配置失误的可能。

Java中的防范方法

Java中常用的XML解析器包括DOM、SAX、StAX等。以DOM解析为例，正确的配置如下：

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;

public class SafeXmlParser {
    public static Document parseXml(String xmlContent) throws Exception {
        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        
        // 最彻底的方案：直接禁止DOCTYPE声明
        factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        
        // 如果业务需要允许DOCTYPE，则至少要禁用外部实体
        // factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
        // factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        
        // 禁用外部DTD
        factory.setXIncludeAware(false);
        factory.setExpandEntityReferences(false);
        
        DocumentBuilder builder = factory.newDocumentBuilder();
        return builder.parse(new ByteArrayInputStream(xmlContent.getBytes("UTF-8")));
    }
}

为什么这样配置？

  • disallow-doctype-decl设为true后，解析器遇到任何DOCTYPE声明都会抛出异常，从根本上杜绝了实体定义的可能性。这是最安全的方式，适用于绝大多数不需要DTD的场景。
  • 如果你的业务确实需要用到合法的DTD（比如某些遗留系统），那就不能禁用DOCTYPE，此时必须显式关闭外部通用实体和外部参数实体，同时关闭XInclude和实体引用扩展。

Python中的防范方法

Python标准库xml.etree.ElementTree默认并不安全，需要手动配置解析器：

import xml.etree.ElementTree as ET
from xml.sax.handler import feature_external_ges, feature_external_pes

def safe_parse_xml(xml_content):
    parser = ET.XMLParser()
    # 禁用外部通用实体
    parser.parser.setFeature(feature_external_ges, False)
    # 禁用外部参数实体
    parser.parser.setFeature(feature_external_pes, False)
    root = ET.fromstring(xml_content, parser=parser)
    return root

如果你使用的是流行的第三方库lxml，配置方式更简洁：

from lxml import etree

def safe_parse_lxml(xml_content):
    parser = etree.XMLParser(
        resolve_entities=False,   # 不解析任何实体
        no_network=True,          # 禁止网络访问
        dtd_validation=False      # 不进行DTD验证
    )
    root = etree.fromstring(xml_content, parser=parser)
    return root

注意：在Python 3.7以上的版本中，xml.etree.ElementTree的默认行为有所改进，但依然建议显式配置以确保安全。

PHP中的防范方法

PHP中最常用的XML解析函数是simplexml_load_string和DOMDocument::loadXML。旧版PHP中需要使用libxml_disable_entity_loader()来禁用外部实体加载：

function safe_simplexml($xml_content) {
    // 禁用外部实体加载
    libxml_disable_entity_loader(true);
    // 使用LIBXML_NONET标志禁止网络访问
    $xml = simplexml_load_string($xml_content, 'SimpleXMLElement', LIBXML_NONET);
    return $xml;
}

重要提示：在PHP 8.0及以上版本中，libxml_disable_entity_loader()函数已被废弃，因为默认情况下外部实体加载已经是禁用的。所以如果你用的是PHP 8+，只需确保不主动开启即可。另外，千万不要使用LIBXML_NOENT常量，因为它会强制解析实体，导致漏洞。

.NET中的防范方法

虽然原文章未提及，但作为补充，.NET开发者也需要留意。在.NET Framework 4.5.2之后，默认的XmlReader已经禁用了外部实体，但老版本仍需手动设置：

using System.Xml;

public static XmlDocument SafeParseXml(string xml)
{
    XmlReaderSettings settings = new XmlReaderSettings();
    settings.DtdProcessing = DtdProcessing.Prohibit; // 禁止DTD处理
    settings.XmlResolver = null;                      // 不使用任何解析器
    
    using (StringReader stringReader = new StringReader(xml))
    using (XmlReader reader = XmlReader.Create(stringReader, settings))
    {
        XmlDocument doc = new XmlDocument();
        doc.Load(reader);
        return doc;
    }
}

四、实战中的注意事项

1. 不要只依赖黑名单过滤

有些开发者试图通过正则表达式过滤<!DOCTYPE或<!ENTITY来防止XXE。这种方法并不可靠，因为攻击者可以使用编码绕过（如十六进制实体编码）、CDATA段等方式绕过检测。正确的做法是在解析器层面彻底禁用功能，而不是在字符串层面做过滤。

2. 注意间接引入XML的情况

有时候应用程序并不直接解析用户提交的XML，而是解析第三方API返回的XML数据。如果那个第三方API本身存在XXE漏洞，你的服务器也可能被间接攻击。因此，即使是你自己信任的来源，也应该使用安全配置去解析。

3. 日志与监控

如果无法立即修复所有XML解析点，可以先在日志中记录每次XML解析的详细信息，包括来源IP、解析的XML片段等，以便发生安全事件时追溯。同时，监控服务器异常的文件读取行为和出站网络连接，有助于及时发现XXE攻击尝试。

五、总结

XXE漏洞虽然历史悠久，但在许多老旧系统或安全意识薄弱的项目中仍然普遍存在。它的本质是XML解析器对外部实体的信任过度。防御措施其实很简单：关闭不需要的功能。无论是Java、Python、PHP还是其他语言，都提供了明确的配置接口。关键在于开发者要有安全意识，在编写XML解析代码时就顺手加上安全配置，而不是等到出了问题再补救。

最后再次强调：如果业务允许，请优先使用JSON或其他轻量级数据格式。XML本身的设计复杂且容易出错，在现代Web应用中已经逐渐被淘汰。但如果你不得不处理XML，请务必牢记本文提到的所有防范方法，让你的代码远离XXE的威胁。

XXE漏洞XML解析XML_external_entity漏洞防范安全配置修改时间：2026-08-20 19:39:51

免责声明：​ 已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰，观点力求客观中立。本站旨在免费分享，内容仅供个人学习、研究或参考使用。若引用了第三方作品，版权归原作者所有。如内容涉及您的权益，请联系我们处理。

上一篇如何用Zapier或Integromat连接XML源和Excel实现自动化

下一篇XPath的=和!=运算符有什么区别？

小编神评

从投入产出比看盲目统一关掉 DTD 在很多环境并不划算，要特别注意不同语言和运行时对外部实体的默认行为差异。比如老版本 PHP 的 libxml 在编译时若没禁掉外部实体，即便代码里设了相关选项仍可能走系统默认而解析外部资源，此时必须显式调用禁用实体加载的函数并配合屏蔽网络解析的全局选项才稳。Java 的某些旧版本 JAXP 实现中，光设置不解析外部实体还不够，内部实体递归膨胀在默认配置下仍可能触发内存暴涨，得额外限制实体展开深度和输入体积。.NET 的 XmlReader 在老框架里如果用了旧式解析器类型，默认会允许 DTD 处理，必须切到不支持 DTD 的读取器并设置资源限额。降级方案是当运行环境不可控或依赖库过旧时，优先在网关层做 XML 体积与结构白名单校验，拒绝带 doctype 的请求，业务侧再统一抛异常退回 JSON 交互；另外对内网元数据地址做出口封锁，避免解析器被诱导访问云实例敏感路径，多环境上线前用最小 payload 在各目标版本实测一遍外部实体是否被真正拒绝。

猜你喜欢
内容垂直聚焦
专注技术核心技术栏目，确保每篇文章深度聚焦于实用技能。从代码技巧到架构设计，为用户提供无干扰的纯技术知识沉淀，精准满足专业提升需求。
知识结构清晰
覆盖从开发到部署的全链路。AI、前端、编程、数据库、服务器、建站、系统层层递进，构建清晰学习路径，帮助用户系统化掌握开发与运维所需的核心技术。
深度技术解析
拒绝泛泛而谈，深入技术细节与实践难点。无论是数据库优化还是服务器配置，均结合真实场景与代码示例进行剖析，致力于提供可直接应用于工作的解决方案。
专业领域覆盖
精准对应开发生命周期。从前端界面到后端编程，从数据库操作到服务器运维，形成完整闭环，一站式满足全栈工程师和运维人员的技术需求。
即学即用高效
内容强调实操性，步骤清晰、代码完整。用户可根据教程直接复现和应用于自身项目，显著缩短从学习到实践的距离，快速解决开发中的具体问题。
持续更新保障
专注既定技术方向进行长期、稳定的内容输出。确保各栏目技术文章持续更新迭代，紧跟主流技术发展趋势，为用户提供经久不衰的学习价值。

负责任网站 - 免责声明 - 隐私政策 - 网站地图

举报邮箱：598330922@qq.com

Copyright (C) www.bbccb.com All Rights Reserved.