XPATH Injection - have you been burned?

[httpwebwitch]

In the application security world, XPATH injection is the unpopular little sibling of SQL injection. The method of attack is identical; the user supplies some crafted input that, when consumed by your application, has unintended consequences: either enumerating (stealing) your data or manipulating it maliciously.

Here's a classic example of SQL injection. This is a query that checks the existence of a name/password combo. Presumably if this query returns any rows, then the user is authenticated to enter the site or do something.

SELECT * FROM users WHERE name = '[red]John[/red]' AND password = '[red]abc123[/red]']

A clever script kiddie can inject some intentional mischief, like this:

SELECT * FROM users WHERE name = '[red]H4x0r'; DROP TABLE users --[/red]' and password = '[red]foo[/red]'

and if they do ... I sure hope you've got a backup!

SQL databases are vulnerable to SQL injection. If you're storing your data as XML (or via an XML interface), your XML is vulnerable to XPATH Injection. If you don't pasteurize user input used in an XPATH query, a mailicious user can turn a useful XPATH expression into a big security hole.

Say your C#/PHP/Perl code expects to build an XPATH like this:

String(//users[@name='[red]John[/red]' and @password='[red]abc123[/red]']">

it may actually be given input like this:

String(//users[@name='[red]H4x0r' OR 1=1 OR 1='[/red]' and @password='[red]foo[/red]']">

Depending on what's present in the XML, the end user may be able to sniff out your entire roster of names and passwords. Or your client mailing list. Or some precious config settings. Who knows! They may be able to grab piles of data with a single query, or it might take thousands of automated queries to grab one letter at a time from every node. There are automated hackerware tools that can find+exploit XPATH vulnerabilities quickly and effectively. And if someone is serious about doing some XPATH injection, they'll probably have and use one.

XPATH injection isn't as seemingly powerful as SQL injection; after all SQL has these fantastic methods like DROP and DELETE and UNION and INSERT... it only takes one crack in the wall and an attacker can do whatever they please all over your tables. With XPATH, usually all an attacker can do is read stuff they aren't allowed to read. But in cases where authentication credentials are exposed, that seemingly small vulnerability can suffice to compromise your entire application.

I've worked with XML for many years, and I've been aware of XPATH injection for about half of those years. I do take precautions to pasteurize user-entered input before putting it in an XPATH or SQL command. Perhaps for that reason, I've never actually seen an XPATH injection up close, personally. SQL injection: yes, I've been injected, and it hurt. XPATH? Can't say I've had the misfortune. Or maybe I have been hit and I don't know it because the attacker left no trace except for some strange crap in my logs.

Were you aware of XPATH injection before reading this post?
If so, do you pasteurize your user input to prevent XPATH injection?

Have any of you been burned by XPATH injection?
If so, what did the attacker do?
What were they after, and what did they get?
How might you have prevented it?

[iamlost]

Were you aware of XPATH injection before reading this post?
If so, do you pasteurize your user input to prevent XPATH injection?

Yes.
Yes.

How might you have prevented it?

As you mention most webdevs have at least heard of SQL injection but code injection by any name is still code injection and can be prevented by similar means.

1. Follow a secure code best practices methodology.
I recommend understanding the OWASP (Open Web Application Security Project) Secure Coding Principles and Web Service Security by Apache.
Specific to XML: IBM's 'Avoid the dangers of XPath injection'

2. Presume all input data is suspect.

3. Validate data format as well as data type.

4. Validate data at least server-side, preferably both client-side and server-side, never ever only client-side.

5. Fuzz Test prior to live use.

You will note that all the above requires knowing somewhat one is doing, cut-n-paste coders (the vast majority of webdevs) will remain at risk.

[incrediBILL]

I'm wondering how anyone ever gets burned with this nonsense unless they're feeding unfiltered input directly into the SQL server which is suicidal at best.

I parse out all programming characters that wouldn't be used in normal names, user IDs or passwords and specific keywords like SELECT, DROP TABLE, etc. so basically all that's left is raw text without any ability to feed in any type of syntactically correct programming language.

FYI, I convert the input string first, unescape all escaped characters, etc.

If you don't, might as well hang a banner on your site "HACK HERE!"

[edited by: incrediBILL at 7:18 pm (utc) on April 19, 2009]

[civgroup]

Also, never give the app DROP privs! Let the app use a db useraccount with only the privs it needs.

[Clark]

If you use Prepared Statements, which is getting better in MySQL, you can avoid many problems. Although I've had some problems where question marks in the data cause crashes because they are used as the placeholder. I believe it is a PHP bug.