EXP-XPath.md

XPath注入

一句话理解

XPath 注入的本质，是用户输入进入 XPath 查询表达式后，改变原本的节点匹配逻辑，从而绕过认证、读取 XML 数据或在无回显场景下进行盲注枚举。

基础理解

XPath 是用于在 XML 文档中定位节点的查询语言，作用类似于“XML 世界里的 SQL”。
因此，当应用把用户输入直接拼进 XPath 表达式时，就会出现与 SQL 注入类似的安全问题。

常见场景

• XML 存储的用户认证
• 旧系统配置查询
• SSO / 身份系统中的 XML 处理
• SOAP / XML WebService
• 本地 XML 配置文件查询

常见危害

• 登录绕过
• 读取 XML 中的敏感字段
• 枚举节点、属性和值
• 在无回显场景下做盲注

常见成因

• 直接字符串拼接 XPath
• 认为 XML 不是数据库，因此忽略注入风险
• 只做简单引号替换，没有参数化或安全构造

典型利用思路

1. 认证绕过

若查询类似：

//users/user[name='$name' and password='$pass']

攻击者可通过构造逻辑表达式改变匹配条件，实现认证绕过。

2. 条件控制

常见利用与 SQL 注入类似，围绕：

• or
• and
• 字符串闭合
• 节点条件变形

3. 盲注枚举

若结果只返回真假，可通过字符比较逐步枚举：

• 节点名
• 属性名
• 节点值

实战排查思路

1. 先判断后端是否使用 XML 存储或查询

重点看：

• 用户认证逻辑
• XML 配置解析
• SOAP 相关接口
• 旧系统单点登录

2. 再看输入是否进入 XPath

关注：

• 字符串拼接构造 XPath
• 认证条件
• 搜索过滤条件

3. 再判断回显类型

区分：

• 直接回显
• 报错回显
• 布尔盲注

常见绕过思路

1. 引号闭合

若原查询使用单引号或双引号，需要先判断闭合方式。

2. 布尔逻辑控制

和 SQL 注入类似，可通过真假表达式测试当前注入点是否成立。

3. 无回显场景

若无法直接读值，就退到布尔盲注，逐字符枚举 XML 节点和属性。

防御要点

1. 不拼接 XPath

应使用安全的参数绑定、预定义查询或安全构造 API。

2. 做输入校验

对用户输入做类型限制、白名单限制，避免进入 XPath 语法结构。

3. 最小化错误信息

不要把完整 XPath 异常和 XML 结构直接返回前端。

4. 尽量避免用 XML 处理敏感认证逻辑

历史系统中这类场景尤其常见，应优先改造。

速查清单

• 先确认是否存在 XML 查询和认证逻辑
• 先测试引号闭合和真假条件
• 再判断是否可直接回显或只能盲注
• 重点排查老系统、SSO、SOAP、XML 配置查询
• 把 XPath 注入当成“XML 版 SQL 注入”来建立思路

Reference

• XPath 注入指北