XPath 注入的原理
有些系统把数据放在 XML 里并用 XPath 查询，注册、检索与登录校验都可能由 XPath 表达式驱动。如果把用户输入直接拼进表达式，攻击者可以用引号与运算符改变查询语义，例如让条件恒真绕过校验，或改变节点选择范围读到本不该返回的记录。它的形态与 SQL 注入相似，但操作对象是 XML 节点树。
基本信息
| 常见入口 | XML 驱动的检索、配置查询、老系统登录校验 |
|---|---|
| 触发信号 | 返回结果范围变化、表达式解析错误、响应长度突变 |
| 典型元字符 | 单引号、括号、or 与 and、方括号谓词 |
| 修复方向 | 使用支持参数绑定的 XPath 接口，不拼接字符串 |
| 处理原则 | 只做存在性验证，不提取数据 |
典型使用场景
- 老系统接手评估：确认检索与登录是否由 XML 数据驱动
- 开发自查复核：核验新代码是否改用参数化查询
- 告警核实：安全设备报出可疑查询时确认是否真实可利用
- 复测：按原最小样本重放，确认修复后不再改变语义
- 报告取证：记录参数与现象差异，不落库、不导出数据
验证步骤
验证步骤
1. 找出由 XML 数据支撑的查询功能，确认参数进入表达式
2. 提交含 XPath 元字符的取值，观察结果集范围与条数变化
3. 出现解析错误时记录完整错误信息，判断是否泄露表达式结构
4. 对照正常请求确认差异确实来自表达式语义变化
5. 记录参数、请求与现象差异，不提取数据即停止现象与判定
| 现象 | 可能原因 | 判定与处置 |
|---|---|---|
| 结果条数变多 | 条件被改写为恒真 | 存在注入，按高优先级处理 |
| 返回解析错误 | 表达式语法被破坏 | 结合错误信息判断，注意信息泄露 |
| 请求被拒或超时 | 输入被过滤或查询代价过高 | 换写法复验，避免只凭单次结果下结论 |
| 无任何变化 | 参数未进入表达式或已被绑定 | 记录为未发现问题，注明验证方法 |
修复视角：使用支持参数绑定的 XPath API，或在解析阶段做白名单校验，而不是把输入拼进表达式字符串。
报错页面常直接回显表达式原文：这类信息泄露单独记一条，它本身就能帮助后续利用。