xxe外部实体注入攻击无法getshell
我见过太多人把xxe当万能钥匙。部实某次渗透测试，体注目标是入攻一个企业级文档解析服务，接口接受XML格式的击无元数据。我扔了个经典payload——<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>——响应里果然吐出了root行。部实当时心里一喜，体注顺手就尝试读/root/.ssh/id_rsa，入攻结果直接404。击无再试expect://协议想执行命令，部实服务端报错“unsupported protocol”。体注
这就是入攻xxe的尴尬：它擅长读文件，但离getshell还差着十万八千里。击无原因很简单，部实外部实体解析器大多只支持http、体注file这类被动协议，入攻expect、php://input这些能触发代码执行的通道早被默认禁用。就算你读到web.config或application.yml里的数据库密码，那也只是拿到了“进入后台的钥匙”，不是“操作系统的控制权”。
换个角度想，xxe能getshell的场景基本都依赖“组合拳”。比如你读到了某个内部管理接口的凭证，再配合SSRF去打内网的Jenkins或Redis，那才算摸到shell的门槛。可这中间每一步都要碰运气——目标系统得开着相关服务，防火墙得放行内网流量，甚至你读到的配置文件里得有明文密码。大多数真实业务系统，早把这些口子堵死了。
有个案例让我印象很深。某次授权测试，xxe能读任意文件，但目标跑在容器里，没有cron、没有ssh key、连/tmp都只读。折腾半天，唯一能利用的是读/proc/self/environ拿到一个临时环境变量，里面有个API token，结果那token权限只够查询订单状态。最后报告里只能写“可读取敏感文件，建议升级解析库”，连个高危都算不上。
说句实在话，xxe的价值在于“情报收集”，不在于“直接打穿”。你读到了数据库配置，那就去试弱口令连MySQL；读到了内网IP，那就配合SSRF扫端口。可这些后续动作早脱离了xxe本身，更像是把它当跳板。真正能一步getshell的xxe漏洞，我从业五年只见过两次，一次是PHP的expect模块没禁用，另一次是目标用了老版本Java的RMI反序列化链——这俩都属于“历史遗留问题”，放今天的新系统上根本不存在。
所以下次再遇到xxe，别急着喊“能getshell”。先想想你读到的文件能不能帮你拿到另一个系统的权限，或者能不能直接控制出网流量打内网。如果都不行，那就老老实实报个中危，把修复建议写成“禁用外部实体解析、升级libxml”。这年头，漏洞利用的深度早就不看单个点，而是看你怎么把碎片信息串成一条链。xxe只是链子上的一个环，指望它自己变成砍刀，纯属想多了。