Conference · 2009
Fortifying Applications Against XPath Injection Attacks
Dimitrios Mitropoulos, Vassilios Karakoidas, Diomidis Spinellis
XPath injection is SQL injection's less-discussed sibling: the same unchecked input, a different query language. This paper defends against it by identifying every piece of XPath the application is allowed to run.
- Published in
- MCIS 2009: 4th Mediterranean Conference on Information Systems, pp. 1169--1179, 2009
- Citations
- 18 on Google Scholar, read 5 September 2026 — 8 of 30 by count
- Cite as
- MKS09
The idea
Applications that query XML build XPath expressions out of user input the same way they build SQL, and with the same consequence. Rather than sanitising the input, the scheme catalogues the code: every XPath fragment that exists in the application is identified and given a unique id derived from the fragment and its call site. At execution time, an expression that does not match a known identifier is not the program's own, and does not run.
Contributions
- XPath code identification — all XPath the application can execute is enumerated and associated with unique identifiers, so unwanted code is blocked.
- Detailed logging of every XPath execution, reviewable afterwards to find the application's weak spots.
- Transparent use — the mechanism acts as a proxy in front of the existing XPath library, so application code does not change.
Where it sits
The approach was generalised two years later to SQL, XPath and JavaScript together in Countering Code Injection Attacks.
Written from the paper itself — the PDF linked above, which this site hosts.