xml注入漏洞

去年帮一个朋友看他的入漏电商后台，登录框里输入一个单引号，入漏页面直接甩回来一段SQL报错。入漏他以为只是入漏SQL注入，我顺手在URL参数里塞了个<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>，入漏数据库没崩，入漏但服务器上的入漏文件内容被原样吐到了前端。他愣了半天——这玩意儿跟SQL注入完全两码事。入漏

XML注入的入漏核心不在标签本身，而在解析器怎么“信任”你给的入漏输入。很多开发者觉得XML就是入漏个数据格式，跟JSON差不多，入漏解析一下拿字段就完事了。入漏问题出在DTD（文档类型定义）上。入漏XML规范允许在文档里定义实体，入漏实体可以引用外部资源，也可以嵌套展开。解析器默认会老老实实按规则执行。你输入一个自定义实体，它就去读文件、发请求、甚至递归展开到内存爆掉。

最常见的两种利用方式：XXE和XEE。XXE是外部实体注入，上面那个读/etc/passwd就是典型。XEE是实体扩展，也叫“十亿 laughs”攻击——定义一层套一层的实体，解析器展开时内存直接吃满。我见过一个真实案例，某企业内部的SOAP接口没做任何过滤，攻击者发了一个带递归实体的请求，服务端CPU飙到100%，重启都来不及，整个订单系统瘫了四十分钟。

为什么这种漏洞反复出现？因为很多语言的XML解析库默认开启外部实体。Java的DocumentBuilderFactory、Python的lxml、PHP的libxml，默认行为都不安全。开发者调个parse()就以为完事了，根本不知道底下发生了什么。更麻烦的是，有些框架把XML解析藏得很深——比如Spring的某些版本处理XML配置文件时，或者WebService的SOAP消息解析。你写业务代码时压根没碰XML，漏洞却已经在依赖库里埋好了。

防御手段其实不复杂，但得做对。第一，禁用外部实体。Java里设置factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)，Python的lxml用resolve_entities=False，PHP在libxml_disable_entity_loader(true)之后解析。第二，如果业务确实需要DTD，那就白名单限制实体来源，别让它随便读本地文件或发网络请求。第三，别用XML就别用——很多场景JSON完全够，非要上XML就是给自己找事。

有个细节值得注意：XXE不光能读文件，还能做SSRF。攻击者构造一个外部实体指向内网地址，解析器就会替你发请求。我试过一个场景，目标服务器能访问内网的Redis，通过XXE让解析器去连http://127.0.0.1:6379，虽然拿不到回显，但Redis的响应时间差异能用来做端口扫描。这种盲XXE在实战里特别恶心，日志里连个报错都没有。

最后说个观察。很多安全扫描器对XML注入的检测很粗糙，就发个带<!ENTITY的payload看响应里有没有root:。但真实环境里，解析器可能把错误吞掉，或者实体展开后做了编码转换。我见过一个接口，XXE能读文件，但读出来的内容被Base64编码后塞在JSON的某个字段里，扫描器完全没反应。手动测的时候，别只看报错，多看看响应体里有没有莫名其妙多出来的数据——那可能就是文件内容换了层皮。