Reino: Input Validation and Representation
Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.
XSLT Injection
Abstract
O processamento de uma folha de estilos XSL inválida pode permitir que um invasor altere a estrutura e o conteúdo do XML resultante, inclua arquivos arbitrários do sistema de arquivos ou execute código arbitrário.
Explanation
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:
O
1. XSS:
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:
A folha de estilo XSL precedente retornará o conteúdo do arquivo
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.
A folha de estilos precedente executará o comando "cmd.exe" no servidor.
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.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.xslt_injection
Abstract
O processamento de uma folha de estilos XSL inválida pode permitir que um invasor altere a estrutura e o conteúdo do XML resultante, inclua arquivos arbitrários do sistema de arquivos ou execute código arbitrário.
Explanation
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:
O código no
1. XSS:
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:
A folha de estilo XSL precedente retornará o conteúdo do arquivo
3. Execução de código Java arbitrário:
O processador XSLT tem a capacidade de expor métodos de linguagem Java nativa como funções XSLT se eles não estiverem desabilitados.
A folha de estilos anterior executará o comando "ls" no servidor.
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:
...
InputStream xmlUrl = Utils.getFromURL(request.getParameter("xmlurl"));
InputStream xsltUrl = Utils.getFromURL(request.getParameter("xslurl"));
Source xmlSource = new StreamSource(xmlUrl);
Source xsltSource = new StreamSource(xsltUrl);
Result result = new StreamResult(System.out);
TransformerFactory transFact = TransformerFactory.newInstance();
Transformer trans = transFact.newTransformer(xsltSource);
trans.transform(xmlSource, result);
...
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
.3. Execução de código Java arbitrário:
O processador XSLT tem a capacidade de expor métodos de linguagem Java 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:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object">
<xsl:template match="/">
<xsl:variable name="rtobject" select="rt:getRuntime()"/>
<xsl:variable name="process" select="rt:exec($rtobject,'ls')"/>
<xsl:variable name="processString" select="ob:toString($process)"/>
<xsl:value-of select="$processString"/>
</xsl:template>
</xsl:stylesheet>
A folha de estilos anterior executará o comando "ls" no servidor.
References
[1] INJECT-8: Take care interpreting untrusted code Oracle
[2] Standards Mapping - Common Weakness Enumeration CWE ID 494
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[12] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.xslt_injection
Abstract
O processamento de uma folha de estilos XSL inválida pode permitir que um invasor altere a estrutura e o conteúdo do XML resultante, inclua arquivos arbitrários do sistema de arquivos ou execute código arbitrário.
Explanation
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:
O código no
1. XSS:
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:
A folha de estilo XSL precedente retornará o conteúdo do arquivo
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".
A folha de estilo precedente mostrará os resultados do comando "ls" executado no servidor.
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.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.xslt_injection
Abstract
O processamento de uma folha de estilos XSL inválida pode permitir que um invasor altere a estrutura e o conteúdo do XML resultante, inclua arquivos arbitrários do sistema de arquivos ou execute código arbitrário.
Explanation
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:
O código no
1. XSS:
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:
A folha de estilo XSL precedente retornará o conteúdo do arquivo
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
.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.xslt_injection