La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos utilizados para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

...
string acctID = Request["acctID"];
string query = null;
if(acctID != null) {
       StringBuffer sb = new StringBuffer("/accounts/account[acctID='");
       sb.append(acctID);
       sb.append("']/email/text()");
       query = sb.toString();
}

XPathDocument docNav = new XPathDocument(myXml);
XPathNavigator nav = docNav.CreateNavigator();
nav.Evaluate(query);
...

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.




2. Los datos utilizados para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código Objective-C, que llama a las API de C, crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos utilizados para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

query = "/accounts/account[acctID='" & url.acctID & "']/email/text()";
selectedElements = XmlSearch(myxmldoc, query);

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.




2. Los datos utilizados para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

...
    NSString *accountStr = account.text;

    xmlXPathContextPtr xpathCtx;
    NSString *query = @"/accounts/account[actId='" + accountStr + @"']/email/text()";

    xpathCtx = xmlXPathNewContext(doc);

    /* Evaluate XPath expression */
    xmlChar *queryString =
        (xmlChar *)[query cStringUsingEncoding:NSUTF8StringEncoding];
    xpathObj = xmlXPathEvalExpression(queryString, xpathCtx);
...

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

...
<?php
load('articles.xml');
 
$xpath = new DOMXPath($doc);
$emailAddrs = $xpath->query(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;);
//$arts = $xpath->evaluate(&quot;/accounts/account[acctID='&quot; . $_GET[&quot;test1&quot;] . &quot;']/email/text()&quot;)
 
foreach ($emailAddrs as $email)
{
    echo $email->nodeValue."";
}
	?>
...

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XPath se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para crear dinámicamente una consulta XPath.

Ejemplo 1: El siguiente código crea y ejecuta dinámicamente una consulta XPath que recupera una dirección de correo electrónico para un identificador de cuenta dado. El identificador de cuenta se lee desde una solicitud HTTP y, por tanto, no es de confianza.

...
tree = etree.parse('articles.xml')
emailAddrs = "/accounts/account[acctID=" + request.GET["test1"] + "]/email/text()"
r = tree.xpath(emailAddrs)
...

En condiciones normales, como la búsqueda de una dirección de correo electrónico que pertenece al número de cuenta 1, la consulta que ejecuta este código será similar a la siguiente:

/accounts/account[acctID='1']/email/text()

Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si acctID no contiene un carácter de comilla simple. Si un usuario malintencionado introduce la cadena 1' or '1' = '1 para acctID, entonces la consulta será de la siguiente forma:

/accounts/account[acctID='1' or '1' = '1']/email/text()

La adición de la condición 1' or '1' = '1 hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//email/text()

Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las direcciones de correo electrónico almacenadas en el documento, independientemente del propietario especificado.

La inyección de XQuery se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos utilizados para generar dinámicamente una expresión XQuery.

Ejemplo 1: el siguiente código crea y ejecuta dinámicamente una expresión XQuery que recupera una cuenta de usuario para una combinación determinada de nombre de usuario y contraseña. El nombre de usuario y la contraseña se leen de una solicitud HTTP y, por tanto, no son de confianza.

  ...

  String squery = "for \$user in doc(users.xml)//user[username='" + Request["username"] + "'and pass='" + Request["password"] + "'] return \$user";

  Processor processor = new Processor();

  XdmNode indoc = processor.NewDocumentBuilder().Build(new Uri(Server.MapPath("users.xml")));

  StreamReader query = new StreamReader(squery);
  XQueryCompiler compiler = processor.NewXQueryCompiler();
  XQueryExecutable exp = compiler.Compile(query.ReadToEnd());
  XQueryEvaluator eval = exp.Load();
  eval.ContextItem = indoc;

  Serializer qout = new Serializer();
  qout.SetOutputProperty(Serializer.METHOD, "xml");
  qout.SetOutputProperty(Serializer.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Strict//EN");
  qout.SetOutputProperty(Serializer.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
  qout.SetOutputProperty(Serializer.INDENT, "yes");
  qout.SetOutputProperty(Serializer.OMIT_XML_DECLARATION, "no");

  qout.SetOutputWriter(Response.Output);
  eval.Run(qout);

  ...
  

En condiciones normales como, por ejemplo, la búsqueda de una cuenta de usuario con la contraseña y el nombre de usuario correctos, la expresión que ejecuta este código será similar a la siguiente:

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

Sin embargo, dado que la expresión se genera dinámicamente mediante la concatenación de una cadena de consultas de base constante y una cadena de entrada de usuario, la consulta solo funcionará correctamente si el username o la password no contienen un carácter de comilla simple. Si un usuario malintencionado introduce la cadena admin' or 1=1 or ''=' para username, entonces la consulta será de la siguiente forma:

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user

La adición de la condición admin' or 1=1 or ''=' hace que la expresión XQuery siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//user[username='admin']

Esta simplificación de la consulta permite al usuario malintencionado eludir el requisito de que la consulta tenga que coincidir con la contraseña; la consulta devuelve ahora el valor de usuario admin almacenado en el documento, independientemente de la contraseña escrita.

La inyección de XQuery se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.



2. Los datos se utilizan para generar dinámicamente una expresión XQuery.

Ejemplo 1: el siguiente código crea y ejecuta dinámicamente una expresión XQuery que recupera una cuenta de usuario para una combinación determinada de nombre de usuario y contraseña. El nombre de usuario y la contraseña se leen de una solicitud HTTP y, por tanto, no son de confianza.

...

$memstor = InMemoryStore::getInstance();
$z = Zorba::getInstance($memstor);

try {
  // get data manager
  $dataman = $z->getXmlDataManager();

  // load external XML document
  $dataman->loadDocument('users.xml', file_get_contents('users.xml'));

  // create and compile query
  $express =
"for \$user in doc(users.xml)//user[username='" . $_GET["username"] . "'and pass='" . $_GET["password"] . "'] return \$user"

  $query = $zorba->compileQuery($express);

  // execute query
  $result = $query->execute();



?>
...

En condiciones normales como, por ejemplo, la búsqueda de una cuenta de usuario con la contraseña y el nombre de usuario correctos, la expresión que ejecuta este código será similar a la siguiente:

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

Sin embargo, dado que la expresión se genera dinámicamente mediante la concatenación de una cadena de consultas de base constante y una cadena de entrada de usuario, la consulta solo funcionará correctamente si el username o la password no contienen un carácter de comilla simple. Si un usuario malintencionado introduce la cadena admin' or 1=1 or ''=' para username, entonces la consulta será de la siguiente forma:

for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user

La adición de la condición admin' or 1=1 or ''=' hace que la expresión XQuery siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:

//user[username='admin']

Esta simplificación de la consulta permite al usuario malintencionado eludir el requisito de que la consulta tenga que coincidir con la contraseña; la consulta devuelve ahora el valor de usuario admin almacenado en el documento, independientemente de la contraseña escrita.

La inyección de XSLT se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en una hoja de estilos XSL.


Las aplicaciones normalmente utilizan la hoja de estilos XSL para transformar documentos XML de un formato a otro. Las hojas de estilos XSL incluyen funciones especiales que mejoran el proceso de transformación, pero presentan vulnerabilidades adicionales si no se utilizan correctamente.

Si un usuario malintencionado tiene la capacidad de escribir elementos XSL en una hoja de estilos, podrá modificar la semántica de las hojas de estilos XSL y el procesamiento. Un usuario malintencionado podría modificar el resultado de una hoja de estilos de tal modo que se habilite un ataque XSS (Cross-Site Scripting), exponer el contenido de los recursos del sistema de archivos locales o ejecutar un código arbitrario.

Ejemplo 1: aquí se muestra parte del código que es vulnerable a ataques de XSLT:

  ...
  String xmlUrl = Request["xmlurl"];
  String xslUrl = Request["xslurl"];

  XslCompiledTransform xslt = new XslCompiledTransform();
  xslt.Load(xslUrl);

  xslt.Transform(xmlUrl, "books.html");
  ...
  

El Example 1 genera tres vulnerabilidades de seguridad diferentes cuando el atacante pasa el XSL identificado al procesador XSTL:

1. XSS:

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
      <script>alert(123)</script>
    </xsl:template>
  </xsl:stylesheet>

  

Cuando se procesa la hoja de estilos XSL, la etiqueta <script> se representa en el explorador de la víctima, lo que permite la ejecución de un ataque de Cross-Site Scripting.

2. Lectura de archivos arbitrarios en el sistema de archivos del servidor:

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
      <xsl:copy-of select="document('file:///c:/winnt/win.ini')"/>
    </xsl:template>
  </xsl:stylesheet>

  

La hoja de estilos XSL anterior devolverá el contenido del archivo /etc/passwd.

3. Ejecución de código arbitrario:

El procesador XSLT tiene la capacidad de exponer los métodos de lenguaje nativo como funciones XSLT si no se deshabilitan.

  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:App="http://www.tempuri.org/App">
    <msxsl:script implements-prefix="App" language="C#">
      <![CDATA[
        public string ToShortDateString(string date)
          {
              System.Diagnostics.Process.Start("cmd.exe");
              return "01/01/2001";
          }
      ]]>
    </msxsl:script>
    <xsl:template match="ArrayOfTest">
      <TABLE>
        <xsl:for-each select="Test">
          <TR>
          <TD>
            <xsl:value-of select="App:ToShortDateString(TestDate)" />
          </TD>
          </TR>
        </xsl:for-each>
      </TABLE>
    </xsl:template>
  </xsl:stylesheet>

  

La hoja de estilos anterior ejecutará el comando "cmd.exe" en el servidor.

La inyección de XSLT se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en una hoja de estilos XSL.


Las aplicaciones normalmente utilizan la hoja de estilos XSL para transformar documentos XML de un formato a otro. Las hojas de estilos XSL incluyen funciones especiales que mejoran el proceso de transformación, pero presentan vulnerabilidades adicionales si no se utilizan correctamente.

Si un usuario malintencionado tiene la capacidad de escribir elementos XSL en una hoja de estilos, podrá modificar la semántica de las hojas de estilos XSL y el procesamiento. Un usuario malintencionado podría modificar el resultado de una hoja de estilos de tal modo que se habilite un ataque XSS (Cross-Site Scripting), exponer el contenido de los recursos del sistema de archivos locales o ejecutar un código arbitrario. Si el usuario malintencionado tenía el control completo sobre la hoja de estilos enviada a la aplicación, dicho usuario también podría ejecutar un ataque de inyección XXE (entidad externa de XML).

Ejemplo 1: aquí se muestra parte del código que es vulnerable a ataques de XSLT:

...
<?php

$xml = new DOMDocument;
$xml->load('local.xml');

$xsl = new DOMDocument;
$xsl->load($_GET['key']);

$processor = new XSLTProcessor;
$processor->registerPHPFunctions();
$processor->importStyleSheet($xsl);

echo $processor->transformToXML($xml);

?>
...

El código en Example 1 genera tres vulnerabilidades de seguridad diferentes cuando el atacante pasa el XSL identificado al procesador XSTL:

1. XSS:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>

Cuando se procesa la hoja de estilos XSL, la etiqueta <script> se representa en el explorador de la víctima, lo que permite la ejecución de un ataque de Cross-Site Scripting.

2. Lectura de archivos arbitrarios en el sistema de archivos del servidor:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:copy-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>

La hoja de estilos XSL anterior devolverá el contenido del archivo /etc/passwd.

3. Ejecución de código arbitrario de PHP:

El procesador XSLT tiene la capacidad de exponer los métodos de lenguaje nativo de PHP como funciones XSLT al habilitar "registerPHPFunctions".

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:value-of select="php:function('passthru','ls -la')"/>
</xsl:template>
</xsl:stylesheet>

La hoja de estilos anterior dará como resultado la ejecución del comando "ls" en el servidor.

La inyección de XSLT se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en una hoja de estilos XSL.


Las aplicaciones normalmente utilizan la hoja de estilos XSL para transformar documentos XML de un formato a otro. Las hojas de estilos XSL incluyen funciones especiales que mejoran el proceso de transformación, pero presentan vulnerabilidades adicionales si no se utilizan correctamente.

Si un usuario malintencionado tiene la capacidad de escribir elementos XSL en una hoja de estilos, podrá modificar la semántica de las hojas de estilos XSL y el procesamiento. Un usuario malintencionado podría modificar el resultado de una hoja de estilos de tal modo que se habilite un ataque XSS (Cross-Site Scripting), exponer el contenido de los recursos del sistema de archivos locales o ejecutar un código arbitrario.

Ejemplo 1: aquí se muestra parte del código que es vulnerable a ataques de XSLT:

...
xml = StringIO.StringIO(request.POST['xml'])
xslt = StringIO.StringIO(request.POST['xslt'])

xslt_root = etree.XML(xslt)
transform = etree.XSLT(xslt_root)
result_tree = transform(xml)
return render_to_response(template_name, {'result': etree.tostring(result_tree)})
...

El código en Example 1 genera tres vulnerabilidades de seguridad diferentes cuando el atacante pasa el XSL identificado al procesador XSTL:

1. XSS:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <script>alert(123)</script>
  </xsl:template>
</xsl:stylesheet>

Cuando se procesa la hoja de estilos XSL, la etiqueta <script> se representa en el explorador de la víctima, lo que permite la ejecución de un ataque de Cross-Site Scripting.

2. Lectura de archivos arbitrarios en el sistema de archivos del servidor:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:copy-of select="document('/etc/passwd')"/>
  </xsl:template>
</xsl:stylesheet>

La hoja de estilos XSL anterior devolverá el contenido del archivo /etc/passwd.