1. Introduction
Similar to SQL Injection, XPath Injections operate on web sites that uses user-supplied information to construct an XPath query for XML data. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured, or access data that he may not normally have access to. He may even be able to elevate his privileges on the web site if the XML data is being used for authentication (such as an XML based user file).
XPath Injections might be even more dangerous than SQL Injections since XPath lacks access control and allows querying of the complete database (XML document), whereas many SQL databases have meta tables that cannot be accessed by regular queries.
1.1. Typical real-world attack
Suppose that the following XML file is used to keep track of a system's users:
The code to authenticate users composes an XPath query as follows:
String xpathQuery = "//user[name/text()='" + request.get("username") + "' And password/text()='" + request.get("password") + "']";
An example of a successful XPath injection attack to this web application is to specify
lol' or 1=1 or 'a'='a
as username. This would modify the XPath query and bypass authentication.
1.2. What it does
The XPath Injection Security Scan tries to attack the web service by replacing the TestStep's original parameters with malicious strings, designed to expose potential flaws in web services that are using user input in XPath expressions. By using assertions, you can assure that the attack didn't expose sensitive data, return a session ID, etc.
2. Usage
Start by specifying which parameters to inject malicious XPath code into by using the Add, Remove, Copy, Clone and Extract all buttons 
. The Extract all button will extract all non-empty parameters from the tested request.
Then add assertions using the controls at the bottom of the window 
that checks if the injection succeeded. Some assertions that would typically make sense for the XPath Injection Security Scan is:
- XPath Match, e.g. to look for a session ID that reveals an unauthorized login.
- Sensitive Information Exposure, to make sure that the database or database wrapper does not crash and expose server internals.
- Valid HTTP Status Codes, e.g. to assert that the request does not return a 5xx status code (Server Error).
These assertions will be added/suggested automatically if the Security Test is generated by the Security Test Wizard in ReadyAPI.
2.1. Configuration
The Strategy tab 
lets you configure if the scan should be run on failed TestSteps, how long it should wait between each request and how SoapUI should combine attacks on multiple parameters:
- The One by One strategy iteratively tests each malicious value for each selected parameter, leaving all parameters but the currently tested at their original value.
- The All at Once strategy iterates through the list of malicious values just once, applying the same malicious value to all selected parameters.
From the Advanced tab 
you can review and edit the list of malicious strings used by the XPath injection scan.
3. Further reading
Read more about XPath Injections and how to protect yourself at the following websites: