XPath Injection attacks – the “other white meat”?

Everyone knows about securing apps from SQL injection attacks, but how many of you have given consideration to XPath injection protection?  

This (PDF:"Blind Xpath Injection") is a good introduction. A short excerpt shows why XPath injection can be more dangerous than it's SQL cousin:


This approach is even more powerful with XPath than it is with SQL, due to the following characteristics of XPath:

  • XPath 1.0 is a standard language. SQL has many dialects all based on a common, relatively weak syntax.
  • XPath 1.0 allows one to query all items of the database (XML objects). In some SQL dialects, it is impossible to query for some objects of the database
    using an SQL SELECT query (e.g. MySQL does not provide a table of tables ).
  • XPath 1.0 has no access control for the database , while in SQL, some parts of the database may be inaccessible due to lack of privileges to the application.

Take the general reasoning in the doc, add the lack of a native XPath equivalent to ADO.NET parameterized queries, and this has the potential to cause some major headaches in the future.


Comments (8)
  1. On the other hand, you only risk information disclosure, whereas the dangers of SQL injection usually are the complete destruction of your database and/or taking control of the machine if the dba is careless enough.

    So as usual, validate and escape user data, and don’t store unencoded secrets in a xml file.

  2. Addy Santo says:

    You are correct, however I would suggest that theft of data is much more severe than a mere server crash. One is typically remedied by a simple restore operation, while the other is irreversible and cause serious monetary losses, not to mention tarnished reputations.

    Do you think Valve would have been in worse shape if someone crashed their database instead of stealing the halflife 2 codebase? I doubt it.

Comments are closed.

Skip to main content