I've long wanted to introduce this method but never got round to it really. To start off, this writing will discuss some not so common vulnerabilities caused by file and vector transformations by the XSLT processor. So to say, XSL is generally CSS for XML. Acunetix describes this as XSL injection. Before we get to anything in specific, enable the php_xsl extension on Apache (if you're using it). I'll be describing the following methods of transformation:
*XSLTProcessor::__construct - create an XSLTP object *XSLTProcessor::transformToXML - transforming XSL to XML *XSLTProcessor::ImportStyleSheet
- importing style sheets[/i] *XSLTProcessor::registerPHPFunctions - self-explanatory
Some of the basic XSLT elements which apply in these occasions and generally as well:
We created the instances for the DOM and the processor, afterwards we load the XML to be converted and echo out the result. Here is the XML structure that we load. We'll be using it for the rest of the examples so I won't be copying it all the time.
In other occasions we would be specifying the XML through a form or including it locally but since there is no need of similar things since we just want to present the vulnerability; ain't nothing more fancy. So far executions are only limited to client-sided exploitation. Now let's look at the registerPHPFunctions example.
The function enables us to use PHP alike functions as XSLT ones. However, they obey certain syntax which is the following:
$doc = new DOMDocument();
$xsl = new XSLTProcessor();
$xsl->registerPHPFunctions(); // Enable the function
$doc->load('styles.xml'); // We reuse the variable though it's not practical
Now we can pretty much run any command unless the second restrict parameter has been used to disallow certain functions. Let's take the following XSL for instance: