Blind XPath Injection - Revision history

Andrew Smith at 02:17, 31 May 2013

2013-05-31T02:17:56Z

Andrew Smith: Updated description, corrected spelling errors, updated references with working links

2013-05-31T02:13:58Z

Updated description, corrected spelling errors, updated references with working links

KirstenS at 23:20, 7 April 2009

2009-04-07T23:20:49Z

Sstroup: /* Boolenization */

2009-03-10T21:13:53Z

‎Boolenization

KirstenS at 19:52, 4 March 2009

2009-03-04T19:52:45Z

KirstenS at 01:38, 17 February 2009

2009-02-17T01:38:19Z

KirstenS: /* XML Crawling */

2009-02-12T15:17:00Z

‎XML Crawling

KirstenS: /* Examples */

2009-02-12T13:33:01Z

‎Examples

KirstenS: /* Description */

2009-02-12T13:31:59Z

‎Description

KirstenS at 01:06, 14 September 2008

2008-09-14T01:06:40Z

@@ Line 110: / Line 110: @@
 * http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
 * http://www.ibm.com/developerworks/xml/library/x-xpathinjection/index.html
+* http://projects.webappsec.org/w/page/13247005/XPath%20Injection
 [[Category:Injection]]
 [[Category:Attack]]

@@ Line 9: / Line 9: @@
 XPath is a type of query language that describes how to locate specific elements (including attributes, processing instructions,
-etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath
+etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL), however, XPath is different in that it
-can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries.
+can be used to reference almost any part of an XML document without access control restrictions. In SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain databases, tables, columns, or queries. Using an XPATH Injection attack, an attacker is able to modify the XPATH query to perform an action of his choosing.
-More information may be found in the article dedicated to [[XPATH Injection]]. Using an XPATH Injection attack the attacker is able to log in to the system without entering valid login and password. If he wants to know information about other users he must take one step further. When conducting a Blind XPath Injection attack, the attacker has no knowledge about the structure of the XML document. However his situation is better compared to [[Blind SQL Injection]], because there are functions which allow for performing tests (XML Crawling) and in the end getting to know the document structure.
+Blind XPath Injection attacks can be used to extract data from an application that embeds user supplied data in an unsafe way. When input is not properly sanitized, an attacker can supply valid XPath code that is executed. This type of attack is used in situations where the attacker has no knowledge about the structure of the XML document, or perhaps error message are suppressed, and is only able to pull once piece of information at a time by asking true/false questions(booleanized queries), much like [[Blind SQL Injection]].
 ==Risk Factors==
@@ Line 20: / Line 22: @@
 ==Examples==
-The attacker may be successful using two methods: Boolenization and XML Crawling. By adding to the XPath syntax, the attacker uses additional expressions (replacing what the attacker entered in the place of login to the specially crafted expression).
+The attacker may mount a successful attack using two methods: Boolenization and XML Crawling. By adding to the XPath syntax, the attacker uses additional expressions (replacing what the attacker entered in the place of the injection).
 ===Boolenization===
-Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to the account. Successfull log in would equal "True" and failed log in attempt would equal "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.
+Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to an account in a web application. A Successful log in would return "True" and failed log in attempt would return "False". Only a small portion of the information is targeted via the analyzed character or number. When the attacker focuses on a string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.
-Using a ''string-length(S)'' function, where S is a string, the attacker may find out the length of this string. With the appropriate number of ''substring(S,N,1)'' function iterations, where S is a previously mentioned string, N is a start character, and "1" is a next character counting from N character, the attacker is able to find out the whole string.
+Using a ''string-length(S)'' function, where S is a string, the attacker may find out the length of this string. With the appropriate number of ''substring(S,N,1)'' function iterations, where S is a previously mentioned string, N is a start character, and "1" is a next character counting from N character, the attacker is able to enumerate the whole string.
@@ Line 90: / Line 92: @@
 out the rest of expresssion. To omit this limitation the attacker should use OR expressions to void all expressions, which may disrupt the attack.
-Because of ''Boolenization'' the number of queries, even within a small XML document, may be very high (thousands, houndred of thousands and more). That is why this attack is not conducted manually. Knowing few basic XPath functions the attacker is able to write an application in a short time, which will rebuild the structure of the document and will fill it with data by itself.
+Because of ''Boolenization'' the number of queries, even within a small XML document, may be very high (thousands, houndred of thousands and more). That is why this attack is not conducted manually. Knowing a few basic XPath functions, the attacker is able to write an application in a short time which will rebuild the structure of the document and will fill it with data by itself.
 ==Related [[Threat Agents]]==
@@ Line 106: / Line 108: @@
 ==References==
-* http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
+* http://dl.packetstormsecurity.net/papers/bypass/Blind_XPath_Injection_20040518.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
-* http://www.ibm.com/developerworks/xml/library/x-xpathinjection.html
+* http://www.ibm.com/developerworks/xml/library/x-xpathinjection/index.html
 [[Category:Injection]]
 [[Category:Attack]]

← Older revision		Revision as of 23:20, 7 April 2009
Line 2:		Line 2:
	<br>		<br>
	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]
−	~~[[ASDR Table of Contents]]~~

← Older revision		Revision as of 21:13, 10 March 2009
Line 24:		Line 24:

	===Boolenization===		===Boolenization===
−	Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to the account. Successfull log in would be equal "True" and failed log in attempt would equal "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.	+	Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to the account. Successfull log in would equal "True" and failed log in attempt would equal "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.

@@ Line 25: / Line 25: @@
 ===Boolenization===
 Using the "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the aim of the attacker is to log in to the account. Successfull log in would be equal "True" and failed log in attempt would equal "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.
-[[Category:FIXME|I couldn't understand what was meant by this sentence:  Only a smart portion of the information is analyzed "character" or the number. Can you take a look? ]]

@@ Line 2: / Line 2: @@
 <br>
 [[Category:OWASP ASDR Project]]
-[[ASDR Table of Contents]]__TOC__
+[[ASDR Table of Contents]]
@@ Line 19: / Line 19: @@
 TBD
 ==Examples==
@@ Line 95: / Line 94: @@
 ==Related [[Threat Agents]]==
-[[Category:FIXME|need links]]
+TBD
 ==Related [[Attacks]]==

@@ Line 89: / Line 89: @@
 </pre>
-The XPath syntax may remind you of common [[SQL_Injection]] attacks but the attacker must consider that this language disallows commenting
+The XPath syntax may remind you of common [[SQL Injection]] attacks but the attacker must consider that this language disallows commenting
 out the rest of expresssion. To omit this limitation the attacker should use OR expressions to void all expressions, which may disrupt the attack.

@@ Line 99: / Line 99: @@
 ==Related [[Threat Agents]]==
 [[Category:FIXME|need links]]
-TBD
+* TBD
 ==Related [[Attacks]]==
 * [[Blind_SQL_Injection]]
 * [[XPATH_Injection]]
 ==Related [[Vulnerabilities]]==
 * [[Injection_problem]]
 ==Related [[Controls]]==
 * [[:Category:Input Validation]]
 ==References==
 * http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
 * http://www.ibm.com/developerworks/xml/library/x-xpathinjection.html