This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for XPath Injection (OTG-INPVAL-010)"

From OWASP
Jump to: navigation, search
(Short Description of the Issue)
(Corrected link to reference [1] Previous link was outdated.)
 
(26 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v4}}
{{Template:OWASP Testing Guide v2}}
 
  
== Brief Summary ==
+
== Summary ==
XPath is a language that has been designed and developed to operate on data that is described with XML. The XPath injection allows an attacker to inject XPath elements in a query that uses this language. Some of the possible goals are to bypass authentication or access information in an unauthorized manner.<br>
+
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject XPath syntax into a request interpreted by the application, allowing an attacker to execute user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.
  
== Short Description of the Issue ==
 
Web applications heavily use databases to store and access the data they need for their operations. Since the dawn of the Internet, relational databases have been by far the most common paradigm, but in the last years we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath, which is their standard interrogation language. Since from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that also XPath injection attacks follow the same logic of SQL Injection ones. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large slice of the techniques that can be used in a SQL Injection attack leverages the peculiarities of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, there are not ACLs enforced, as our query can access every part of the XML document.<br>
 
  
== Black Box testing and example ==
+
Web applications heavily use databases to store and access the data they need for their operations. Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language.
The attack pattern was first published by Amit Klein (see References at the bottom of the page) and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following xml file:
+
 
 +
 
 +
Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic as [[SQL Injection]] attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the characteristics of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document.<br>
 +
 
 +
 
 +
== How to Test ==
 +
The XPath attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following XML file:
 +
 
 
<pre>
 
<pre>
 
<?xml version="1.0" encoding="ISO-8859-1"?>  
 
<?xml version="1.0" encoding="ISO-8859-1"?>  
Line 30: Line 34:
 
</users>  
 
</users>  
 
</pre>
 
</pre>
 +
 +
 
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
 
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
 +
 
<pre>
 
<pre>
string(//user[username/text()='gandalf' and  
+
string(//user[username/text()='gandalf' and password/text()='!c3']/account/text())  
password/text()='!c3']/account/text())  
 
 
</pre>
 
</pre>
If the application does not properly filter such input, the attacker will be able to inject XPath code and interfere with the query result. For instance, the attacker could input the following values:
+
 
 +
 
 +
If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:
 +
 
 
<pre>
 
<pre>
 
Username: ' or '1' = '1  
 
Username: ' or '1' = '1  
 
Password: ' or '1' = '1  
 
Password: ' or '1' = '1  
 
</pre>
 
</pre>
Looks quite familiar, doesn't it ?  
+
 
Using these parameters, the query becomes:  
+
 
 +
Looks quite familiar, doesn't it? Using these parameters, the query becomes:  
 +
 
 
<pre>
 
<pre>
 
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())  
 
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())  
 
</pre>
 
</pre>
As in a common SQL Injection attack, we have created a query that is always evaluated as true, which means that the application will authenticate the user even if a username or a password have not been provided.
 
  
And as in a common SQL Injection attack, also in the case of XPath inhection the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query and check whether the application returns an error message.
 
  
If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us in reconstruct its internal logic, it is possible to perform a fully blind attack whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. Also this technique is explained in more detail by Amit Klein in the referenced paper.
+
As in a common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided. And as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.
 +
 
 +
 
 +
If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
 
<br>
 
<br>
== Gray Box testing and example ==
+
 
'''Testing for Topic X vulnerabilities:'''<br>
+
 
...<br>
 
'''Result Expected:'''<br>
 
...<br><br>
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
* XPath 1.0 specifications - http://www.w3.org/TR/xpath
+
* [1] Amit Klein: "Blind XPath Injection" - http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf
* Amit Klein: "Blind XPath Injection" - https://www.watchfire.com/securearea/whitepapers.aspx?id=9
+
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath
 
<br>
 
<br>
 
 
{{Category:OWASP Testing Project AoC}}
 

Latest revision as of 16:05, 21 January 2015

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Summary

XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject XPath syntax into a request interpreted by the application, allowing an attacker to execute user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.


Web applications heavily use databases to store and access the data they need for their operations. Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language.


Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic as SQL Injection attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the characteristics of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document.


How to Test

The XPath attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following XML file:

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
<user> 
<username>gandalf</username> 
<password>!c3</password> 
<account>admin</account> 
</user> 
<user> 
<username>Stefan0</username> 
<password>w1s3c</password> 
<account>guest</account> 
</user> 
<user> 
<username>tony</username> 
<password>Un6R34kb!e</password> 
<account>guest</account> 
</user> 
</users> 


An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:

string(//user[username/text()='gandalf' and password/text()='!c3']/account/text()) 


If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:

Username: ' or '1' = '1 
Password: ' or '1' = '1 


Looks quite familiar, doesn't it? Using these parameters, the query becomes:

string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text()) 


As in a common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided. And as in a common SQL Injection attack, with XPath injection, the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.


If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us reconstruct its internal logic, it is possible to perform a Blind XPath Injection attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. Blind XPath Injection is explained in more detail by Amit Klein in the referenced paper.


References

Whitepapers