Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

...
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);
...

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma cadeia de caracteres de consulta base constante e de uma cadeia de caracteres de entrada do usuário, ela se comportará corretamente somente se acctID não contiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.




2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código Objective-C, que chama APIs C, constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

...
    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);
...

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma string de consulta base constante e de uma string de entrada do usuário, ela apenas se comportará corretamente se acctID não contiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

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

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma string de consulta base constante e de uma string de entrada do usuário, ela apenas se comportará corretamente se acctID não contiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.




2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

...
    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);
...

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente por meio da concatenação de uma string de consulta base constante e de uma string de entrada do usuário, ela apenas se comportará corretamente se acctID não contiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

...
<?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."";
}
	?>
...

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente pela concatenação de uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada de usuário, a consulta só se comportará corretamente se acctID não tiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XPath ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta XPath.

Exemplo 1: O seguinte código constrói e executa dinamicamente uma consulta XPath que recupera um endereço de email para uma determinada ID de conta. A ID de conta é lida de uma solicitação HTTP e, portanto, não é confiável.

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

Em condições normais, tais como ao procurar um endereço de email que pertence à conta número 1, a consulta que esse código executa será parecida com a seguinte:

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

No entanto, como a consulta é construída dinamicamente pela concatenação de uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada de usuário, a consulta só se comportará corretamente se acctID não tiver um caractere de aspas simples. Se um invasor inserir a string 1' or '1' = '1 para acctID, a consulta se tornará a seguinte:

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

A adição da condição 1' or '1' = '1 faz com que a cláusula "where" sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//email/text()

Essa simplificação da consulta permite que o invasor ignore o requisito de que a consulta deva retornar somente itens de propriedade do usuário autenticado. A consulta agora retorna todos os endereços de email armazenados no documento, independentemente do proprietário especificado.

Uma injeção de XQuery ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados utilizados para construir dinamicamente uma expressão XQuery.

Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.

  ...

  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);

  ...
  

Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:

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

No entanto, como a expressão é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, ela se comportará corretamente somente se username ou password não contiver um caractere de aspas simples. Se um invasor inserir a string admin' or 1=1 or ''=' para username, a consulta se tornará a seguinte:

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

A adição da condição admin' or 1=1 or ''=' faz com que a expressão XQuery sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//user[username='admin']

Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deva corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.

Uma injeção de XQuery ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.



2. Os dados são usados para construir dinamicamente uma consulta XQuery.

Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.

...

$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();



?>
...

Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:

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

No entanto, como a expressão é construída dinamicamente pela concatenação de uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada de usuário, a consulta só se comportará corretamente se username ou password não tiver um caractere de aspas simples. Se um invasor inserir a string admin' or 1=1 or ''=' para username, a consulta se tornará a seguinte:

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

A adição da condição admin' or 1=1 or ''=' faz com que a expressão XQuery sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples:

//user[username='admin']

Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deve corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.

Uma injeção de XSLT ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um folha de estilos XLS.


Em geral, os aplicativos usam folhas de estilos XSL para transformar documentos XML de um formato em outro. Folhas de estilos XSL incluem funções especiais que aprimoram o processo de transformação, mas introduzem vulnerabilidades adicionais quando usadas incorretamente.

A semântica de folhas de estilos XSL e processamento poderá ser alterada se um invasor tiver a capacidade de escrever elementos XSL em uma folha de estilos. Um invasor pode alterar a saída de uma folha de estilos de forma a habilitar um ataque de XSS (criação de scripts entre sites), expor o conteúdo de recursos do sistema de arquivos local ou executar código arbitrário.

Exemplo 1: Veja a seguir um código que é vulnerável a Injeção de XSLT:

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

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

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

O Example 1 resulta em três explorações diferentes quando o invasor pode transmitir o XSL identificado ao processador 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>

  

Quando a folha de estilo XSL é processada, a tag <script> é renderizada no navegador da vítima, permitindo a realização de um ataque de criação de scripts entre sites.

2. Leitura de arquivos arbitrários no sistema de arquivos do 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>

  

A folha de estilo XSL precedente retornará o conteúdo do arquivo /etc/passwd.

3. Execução de código arbitrário:

O processador XSLT tem a capacidade de expor métodos de linguagem nativa como funções XSLT se eles não estiverem desabilitados.

  <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>

  

A folha de estilos precedente executará o comando "cmd.exe" no servidor.

Uma injeção de XSLT ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um folha de estilos XLS.


Em geral, os aplicativos usam folhas de estilos XSL para transformar documentos XML de um formato em outro. Folhas de estilos XSL incluem funções especiais que aprimoram o processo de transformação, mas introduzem vulnerabilidades adicionais quando usadas incorretamente.

A semântica de folhas de estilos XSL e processamento poderá ser alterada se um invasor tiver a capacidade de escrever elementos XSL em uma folha de estilos. Um invasor pode alterar a saída de uma folha de estilos de forma a habilitar um ataque de XSS (criação de scripts entre sites), expor o conteúdo de recursos do sistema de arquivos local ou executar código arbitrário. Se o invasor tivesse controle total sobre a folha de estilos enviada ao aplicativo, ele também poderia executar um ataque de injeção de XXE (entidade externa XML).

Exemplo 1: Veja a seguir um código que é vulnerável a Injeção 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);

?>
...

O código no Example 1 resulta em três explorações diferentes quando o invasor pode transmitir o XSL identificado ao processador 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>

Quando a folha de estilo XSL é processada, a tag <script> é renderizada no navegador da vítima, permitindo a realização de um ataque de criação de scripts entre sites.

2. Leitura de arquivos arbitrários no sistema de arquivos do 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>

A folha de estilo XSL precedente retornará o conteúdo do arquivo /etc/passwd.

3. Execução de código PHP arbitrário:

O processador XSLT tem a capacidade de expor métodos de linguagem PHP nativos como funções XSLT habilitando "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>

A folha de estilo precedente mostrará os resultados do comando "ls" executado no servidor.

Uma injeção de XSLT ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um folha de estilos XLS.


Em geral, os aplicativos usam folhas de estilos XSL para transformar documentos XML de um formato em outro. Folhas de estilos XSL incluem funções especiais que aprimoram o processo de transformação, mas introduzem vulnerabilidades adicionais quando usadas incorretamente.

A semântica de folhas de estilos XSL e processamento poderá ser alterada se um invasor tiver a capacidade de escrever elementos XSL em uma folha de estilos. Um invasor pode alterar a saída de uma folha de estilos de forma a habilitar um ataque de XSS (criação de scripts entre sites), expor o conteúdo de recursos do sistema de arquivos local ou executar código arbitrário.

Exemplo 1: Veja a seguir um código que é vulnerável a Injeção 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)})
...

O código no Example 1 resulta em três explorações diferentes quando o invasor pode transmitir o XSL identificado ao processador 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>

Quando a folha de estilo XSL é processada, a tag <script> é renderizada no navegador da vítima, permitindo a realização de um ataque de criação de scripts entre sites.

2. Leitura de arquivos arbitrários no sistema de arquivos do 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>

A folha de estilo XSL precedente retornará o conteúdo do arquivo /etc/passwd.