XPath Injection & Blind XPath Injection Vulnerability
Similar to SQL injection, XPath injection occurs when the site uses the information entered by the user to construct the request for XML data. An attacker sends specially constructed information to the site to explore how the XML used by the site is constructed, and even to obtain data that is not available in the normal way. When XML data is used for account authentication, an attacker can also elevate his privileges. By querying XML with XPath, XPath is a simple, descriptive declaration that allows an XML request to determine the location of some information in XML. (Perhaps equivalent to a path query). Similar to SQL, when looking for information you can specify specific attributes and characteristics to match the information. When you use xml for your website, you typically accept some form of string request to confirm the location of the content and display the content on the page. This input must be reviewed to ensure that does not return the wrong data. XPath is a standard language, its syntax is generally independent, which means that attacks against it can be automated, in this respect with the SQL injection is no different (sqlmap).
an example of bunch of xml:
Suppose we have a Web page user authentication system using the data in the xml, whenever the need to query the user name password, the software will be used to query the user through the XPath, the following is the realization of two languages:
On behalf of the matching node, select the elements of the document without regard to the location of elements, / on behalf of selected from the root node, can also be written:
This XPath expression will take effect when the user enters the username and password normally, but the attacker could construct an invalid username and password and select a specific xml node without knowing what the username and password are. log in. If you select the root node, you can directly expose all the data stored xml.
Username: blah’ or 1=1 or ‘a’=’a
Then the XPath script that looks for the username and the matching password before becomes the //Employee[UserName/text()=’blah’ or 1=1 or ‘a’=’a’ And Password/text()=’blah’] by constructing two or to get around, there’s another trick to use ‘= ‘.
In this case, the password will be independent of the authentication conditions, and the user name and constant, so bypass.
Blind XPath Injection Vulnerability
General XPath injection needs to see the page to return to the error message to determine the structure of xml, blinds in the page does not return an error message when the judge True or False, to infer the page structure. This is similar to the SQL blind.
An attacker could use two methods to create a successful attack: Boolenization and XML Crawling. By adding additional expressions to the XPath syntax to achieve the purpose of the attack.
Using the Boolenization method, an attacker will determine whether the XPath expression he entered returns true or false. Let’s assume that the attacker’s goal is to log into a web application, a successful login should return True and fail instead. Only a small part of the content can be used for analysis. When an attacker concentrates on a string of strings, he may test every word to see which class the string belongs to.
- XML Crawling
To get an XML document structure, an attacker could use some XPath built-in functionality:
+ count(expression): count(//user/child::node()）
+ stringlength(string): string-length(//user[position()=1]/child::node()[position()=2])=6
+ substring(string, number, number): substring((//user[position()=1]/child::node()[position()=2]),1,1)=”a”