Inyección XPath

Last revision (mm/dd/yy): //

Descripción
Es similar a las SQL Injection, Los ataques de Inyección XPath se producen cuando un sitio web usa datos suministrada por un usuario para construir una consulta XPath para datos XML.Mediante el envío de información intencionalmente mal formada al sitio web, un atacante puede averiguar cómo se estructuran los datos XML, o acceder a datos a los que no se suelen tener acceso. El atacante puede incluso ser capaz de elevar sus privilegios en el sitio web si los datos XML se utilizan para la autenticación (por ejemplo, un archivo de usuario basado en XML).

Las consultas XML se realizan con XPath, un tipo de declaración descriptiva simple que permite la consulta XML para localizar una información. Como SQL, puedes especificar ciertos atributos a encontrar, y los patrones a seguir. Cuando se usa XML en un sitio web es común aceptar algún formulario de entrada de cadena de texto para identificar el contenido de localizar y mostrar en la página. Esta entrada  'debe'  ser supervisada para comprobar que no provoca errores en la consulta XPath ni devuelve datos incorrectos.

XPath es un lenguaje estándar; su notación / sintaxis es siempre independiente de la implementación, lo que significa que el ataque puede ser automatizado. No hay comunicaciones diferentes, como ocurre en las solicitudes a las bases de datos SQL.

Debido a que no existe un control de acceso por niveles,es posible obtener el documento completo. No vamos a encontrar ningún tipo de limitación como podía ocurrir en los ataques de inyección SQL.

Ejemplos
Nosotros usaremos este fragmento XML para los ejemplos:

&lt;?xml version="1.0" encoding="utf-8"?&gt; &lt;Employees&gt; &lt;Employee ID="1"&gt; &lt;FirstName&gt;Arnold&lt;/FirstName&gt; &lt;LastName&gt;Baker&lt;/LastName&gt; &lt;UserName&gt;ABaker&lt;/UserName&gt; &lt;Password&gt;SoSecret&lt;/Password&gt; &lt;Type&gt;Admin&lt;/Type&gt; &lt;/Employee&gt; &lt;Employee ID="2"&gt; &lt;FirstName&gt;Peter&lt;/FirstName&gt; &lt;LastName&gt;Pan&lt;/LastName&gt; &lt;UserName&gt;PPan&lt;/UserName&gt; &lt;Password&gt;NotTelling&lt;/Password&gt; &lt;Type&gt;User&lt;/Type&gt; &lt;/Employee&gt; &lt;/Employees&gt;

Supón que tenemos un sistema de autenticación en la web que usa un archivo de este tipo para loguear usuarios. Una vez que el nombre de usuario y la contraseña han sido introducidos el software deberá usar XPath para buscar el usuario:

VB: Dim FindUserXPath as String FindUserXPath = "//Employee[UserName/text='" & Request("Username") & "' And        Password/text='" & Request("Password") & "']"

C#: String FindUserXPath; FindUserXPath = "//Employee[UserName/text='" + Request("Username") + "' And        Password/text='" + Request("Password") + "']";

Con un nombre de usuario normal y una contraseña este XPath debería funcionar, pero un atacante puede enviar un nombre de usuario y contraseña errónea y recibir el nodo XML seleccionado sin saber el usuario o contraseña, como aquí:

Username: blah' or 1=1 or 'a'='a Password: blah

FindUserXPath becomes //Employee[UserName/text='blah' or 1=1 or        'a'='a' And Password/text='blah']

Logically this is equivalent to: //Employee[(UserName/text='blah' or 1=1) or        ('a'='a' And Password/text='blah')]

En este caso, solo la primera parte de el XPath necesita ser cierta. La parte del password se vuelve irrelevante, y parte del nombre de Usuario In this case, only the first part of the XPath needs to be true. The password part becomes irrelevant, and the UserName part will match ALL employees because of the "1=1" part.

Relacionado Threat Agents

 * Command Injection
 * SQL Injection
 * LDAP injection
 * Server-Side_Includes_%28SSI%29_Injection

Relacionado Attacks

 * Blind_SQL_Injection
 * Blind_XPath_Injection

Relacionado Vulnerabilities

 * Category: Input Validation Vulnerability

Relacionado Controls

 * Category:Input Validation
 * Input Validation