Nowadays, a growing list of XSLT processors exist with the purpose of transforming XML documents to other formats such as PDF, HTML or SVG. To this end such processors typically offer a powerful set of functionalities – which, from a security point of view, can potentially pose severe risks.
Within this post, we highlight some of the threats one gets exposed when operating a misconfigured XSLT processor. The goal here is to increase people’s awareness when configuring modern XSLT processors.
Tested XSLT Processors
The subsequent table lists the XSLT processors investigated in our tests.
|XSLT Processor||Manufacturer||License||Windows Version||Linux Version|
|libxslt||Gnome Project||MIT License||1.1.26||1.1.28|
|Saxon-HE||Saxonica Limited||Mozilla Public License V1.0||18.104.22.168||22.214.171.124|
|Saxon-EE||Saxonica Limited||Mozilla Public License V1.0||126.96.36.199||188.8.131.52|
|Xalan-J||Apache Software Foundation||Apache License V2.0||2.7.1||2.7.2|
|Xalan-C||Apache Software Foundation||Apache License V2.0||1.11||1.11|
|MSXML 4.0||Microsoft||Proprietary||4.0 SP3||–|
|MSXML 6.0||Microsoft||Proprietary||SP2 (File Version 6.20.1099)||–|
We divided the security threats exposed by the XSLT processors into six categories:
- Information Disclosure
- Read Files
- Write Files
- Database Access
- Include External Stylesheet
- Code Execution
The results are summarized in following figure:
The above results clearly show that the great functionality of modern XSLT processors comes with a tremendous downside: If used in their default configuration, or otherwise not properly configured, XSLT processors can endanger confidentiality and integrity on XSLT servers or allow the execution of arbitrary code. Even worse, the vulnerable XSLT server might be abused to forge attacks against remote third parties, such as for instance performing anonymous port scans (see example below).
Example: Server Side Port Scanning Forgery
Here, we give a short example of how to misuse the document() function (used to access external XML documents) on a remote XSLT server to forge port scanning against an external third party. In the example, the investigated third party is located on host “example.com“, and tested against port 22 (SSH).
The attacker “Mallory“, trying to learn whether or not port 22 on “example.com” is open or closed, submits the following XSL file to a server “Alice” running a vulnerable XSLT processor.
Next, “Alice” processes the XSL file submitted by “Mallory” and as consequence tries to access the external XML resource located on “example.com“. Dependent on whether or not port 22 is open on “example.com“, a different response is sent back to “Alice“, who finally forwards the result to “Mallory“. Since the result “Mallory” receives is different for open/closed ports, she can learn the port state on “example.com“. Note that in this way “Mallory” has performed the port scan anonymously, since the only party speaking to “example.com” was “Alice“.
For the sample processor libxslt in our test set, the response received by “Mallory” might look like shown below:
|Port Open||parser error : Document is empty|
|Port Close (Timeout)||Operation in progress I/O warning|
|Invalid Host||No such file or directory I/O warning|
In summary, “Mallory” was able to forge a port scanning request from “Alice” against “example.com“.
This blog post is based on a Seminar paper (XSLT Processing Security and Server Side Request Forgeries) written by Emanuel Duss and Roland Bischofberger, in collaboration with Compass Security Schweiz AG:
E. Duss and R. Bischofberger. “XSLT Processing Security and Server Side Request Forgeries: Analyse, Demonstration und Gegenmassnahmen“. Seminar Paper, Hochschule für Technik Rapperswil, Autumn 2014