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

Inyección XPath

From OWASP
Jump to: navigation, search
This is an Attack. To view all attacks, please see the Attack Category page.


Last revision (mm/dd/yy): 08/1/2015


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:

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

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 debe 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 devolverá todos los empleados puesto que parte de "1=1" siempre se cumplirá.

Relacionado Threat Agents

Relacionado Attacks

Relacionado Vulnerabilities

Relacionado Controls