ACTION-126: Call out local system access risks regarding XSLT

ACTION-126: Call out local system access risks regarding XSLT



http://www.w3.org/2008/xmlsec/track/issues/126

The following is my recommended addition to the Best Practices document:
2.1.# Example: XSLT transform that executes arbitrary code
The XSLT transform in the example below makes use of the user-defined extension feature to execute arbitrary code when validating an XML Signature.  The example syntax is specific to the Xalan XSLT engine, but this approach is valid for most XSLT engines.  The example calls "os:exec"  as a user-defined extension, which is mapped to the Java lang.Runtime.exec() method which can execute any program the process has the rights to run.   While the example calls the shutdown command, one should expect more painful attacks if a series of attack signatures are allowed.
If an implementation of XML Signature allows XSLT processing it should disable support for user-defined extensions.
Changing the Transforms element does invalidate the signature.  XSLT transforms should only be processed after first authenticating the entire signature and establishing an appropriate degree of trust in the originator of the message.
Example:
<Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:java="java">
    <xsl:template match="/" xmlns:os="java:lang.Runtime" >
     <xsl:variable name="runtime" select="java:lang.Runtime.getRuntime()"/>
     <xsl:value-of select="os:exec($runtime, 'shutdown -i')" />
    </xsl:template>
   </xsl:stylesheet>
  </Transform>
</Transforms>
Best Practice #: When XSLT is required disallow the use of user-defined extensions
Arbitrary XSLT processing leads to a variety of serious risks, so if the best practice of disallowing XSLT transforms cannot be followed, insure that user-defined extensions are disabled in your XSLT engine.

Thanks, Ken.
_______________________________________________________
Ken Graf, Enterprise Architect                           Intel Americas, Inc

Manageability & Middleware Division, Software and Solutions Group
Phone +1-603-471-1019               email: kenneth.m.graf@intel.com<mailto:kenneth.m.graf@intel.com>

All opinions expressed in this email belong to the author and do
not imply any endorsement, knowledge or consent of Intel or any
Intel related business.