XPATH注入你会吗？一文搞懂这个冷门但致命的漏洞
哎，说到XPATH注入，我估计很多搞安全的朋友第一反应是：“啊？还有这东西？” 哈哈，别笑，我第一次听到的时候也是这个反应，SQL注入大家都熟得不能再熟了，XSS、CSRF更是老生常谈，可XPATH注入这玩意儿，说实话，存在感是真的低，但你要真问我“XPATH注入你会吗”，我还真得认真跟你唠唠——因为这玩意儿虽然冷门，一旦中招,那酸爽程度可不比SQL注入差。
先说说这到底是个啥玩意儿
XPATH注入，说白了就是攻击者通过构造恶意的XPATH查询语句，绕过应用程序原本的验证逻辑，从而窃取XML文档里的数据或者绕过登录认证，你想想啊，现在很多系统还在用XML存数据，配置文件、用户信息、SOAP接口……到处都是XML的影子，而XPATH就是专门用来查询XML的“SQL语句”,只不过它查的是XML节点而已。
我第一次接触XPATH注入的时候，是在一个老掉牙的登录框上，当时我随手在用户名里塞了个 ' or '1'='1，本来以为会触发SQL注入，结果报错信息里蹦出来个“XPATH syntax error”——好家伙，我当时眼睛就亮了！这不就是XPATH注入的经典入口嘛！
它到底怎么玩的？
举个特别简单的例子哈,假设后端代码长这样：
String xpath = "//user[username='" + userInput + "' and password='" + pwd + "']";你看，用户输入直接拼进去了，连个过滤都没有，这时候如果我在用户名框里输入 ' or '1'='1,整个XPATH就变成了：
//user[username='' or '1'='1' and password='...']哎呦喂，这不就直接绕过了嘛！'1'='1' 永远为真，管你密码是啥，登录成功！你说吓人不吓人？
更狠的是，XPATH注入还能玩盲注，比如用 count(//user) 配合条件判断，一个字符一个字符地把整个XML文档的内容给“摸”出来，虽然过程慢得像蜗牛爬，但胜在隐蔽啊，很多WAF根本不管XPATH注入,你说气不气人？
那为啥它这么冷门呢？
我琢磨了一下，原因其实挺现实的，XML这玩意儿现在用得越来越少了，JSON大行其道，很多年轻开发者压根没写过XPATH查询，其次呢，XPATH注入的利用门槛比SQL注入高那么一丢丢，你得懂XPATH语法，还得会构造payload，再加上网上教程少得可怜,大家自然就不怎么关注了。
千万别因为冷门就掉以轻心啊朋友们，我见过太多系统，表面上用的是JSON API，结果底层还是偷偷解析XML，XPATH注入的入口藏得那叫一个深，你要是不信，回头翻翻你项目里的老代码，说不定就藏着几处 XPathExpression 呢,嘿嘿。
怎么防？说点实在的
防XPATH注入，核心思路跟防SQL注入是一个道理——别拼接，用参数化，Java里的 XPathExpression 支持预编译变量，XPathConstants 配合 evaluate 用变量绑定，别偷懒直接字符串拼，输入校验也得做，特殊字符像单引号、双引号、括号、斜杠这些，该转义转义,该拒绝拒绝。
还有一个特别容易忽略的点：错误信息别随便往外抛，XPATH语法错误里经常带着查询语句的片段，攻击者拿到这个就等于拿到了地图，盲注都能给你玩成显注,那可就太亏了。
最后唠两句
所以回到开头那个问题——“XPATH注入你会吗”？现在我可以拍着胸脯说：会，而且我知道它有多坑，安全这行啊，最怕的就是“我以为我会了”，冷门漏洞不代表没威胁，恰恰相反，正因为大家都盯着SQL注入和XSS，XPATH注入这种“小透明”反而成了绝佳的突破口。
行了，今天就唠到这儿，你要是也在项目里发现了XPATH注入的蛛丝马迹，欢迎来评论区聊聊，咱们一起研究研究，说不定又能挖出个大瓜呢！记得点赞转发啊，让更多朋友知道这个冷门但致命的漏洞,咱们下期见～