Coders Conquer Security: Share & Learn Series - XQuery Injection

XQuery injection attacks are sometimes thought of like the little brother to the more prevalent SQL injection attacks. They have similar root causes, and the commands that attackers exploit to trigger them both are also very close. It's just that XQuery injection attacks can only happen during an XPath query for XML data. Because of this, they are sometimes called XPath Injection or just XPath attacks, since that is the delivery method used.

A huge majority of websites use XML databases to perform critical functions such as holding user login credentials, customer information, personal identity information and confidential or sensitive data, leaving XQuery attacks with a rather large attack footprint.

In this episode, we will learn:

• How attackers use XQuery injections
• Why XQuery injections are dangerous
• Techniques that can fix this vulnerability.

How do Attackers Trigger an XQuery Injection?

Like with most computer languages, the code for XPath was designed for simplicity. In fact, XPath is a standard language, and all notations and syntax statements are unchanged regardless of the application using them. This means that the commands used to manipulate an XPath query are well known, and can even be automated.

At its core, an XPath query is a simple statement that tells the XML database what information to lookup. In one of the most simplistic examples, it is used to check to see if a user record exists, and then to retrieve their login credentials. The problem is that because XPath queries include user input, hackers can manipulate the query to return information that should be protected.

For example, when trying to bypass login security, an attacker can add variables to the end of their XPath query that circumvent the entire process. An example might look like this:

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

Here, the User Name field is made to match any user because of the 1=1 or a=a statement. The password field won't even matter, since only the first part of the query needs to be true.

Why is XQuery Injection Dangerous?

A primary reason that XQuery injection attacks are so dangerous is because they allow attackers to bypass login and account security. And they allow it to be done in an automated fashion using a standard language that does not vary by application. Attackers can automatically scan websites and applications for this vulnerability and act as soon as it's discovered. If your app is vulnerable, then the attackers will compromise it. Beyond compromising account security, XQuery attacks can also be used for data exfiltration. For example, an attacker could transfer all records out of the XML database.

Eliminating XQuery Injection Attacks

As with similar vulnerabilities, one key defense is simply not trusting user input. Any time that a user is able to enter information, whether they are making a database query or not, the process should be scrutinized. It's not unlike securing the windows and doors of a physical building, since those are the main ways people can gain access.

For XQuery injection protection, this is done by sanitizing user input through filtering, or by using whitelist input validation of user input. You can also use a parameterized XPath interface, similar to prepared statements for SQL queries.

Finally, be sure to apply least privilege to all applications. That might mean creating a user with read-only privileges to perform all application queries.

By using these techniques, it's possible to stop all XQuery injection attempts made against your website or application.

More Information about XQuery Injections

For further reading, you can take a look at what OWASP says about XQuery Injections. You can also put your newfound defensive knowledge to the test with a free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.