I didn’t even want to write about this, because hopefully it is not a wide spread problem but it is such a catastrophic programming mistake which I saw in a production system that I felt the need to talk about it. So to summarize this blog post in one sentence: total client-side exploit using user defined XSLT.

Let us recap quickly. XSLT stands for XSL Transformation. It is a technique to transform XML documents to XHTML pages. It can be handy in systems where things are stored in XML and they need to be quickly transformed to XHTML pages or to whatever. You can define rules to match to parts of your XML and tell how should it look like in the XHTML. It is actually a cool stuff and no black magic is used. For more info look at the W3school tutorial.

The problem

At first glance there is no problem here and that is true. The problem is not in the technology but in the implementation. It comes when the web application takes the XSLT as a user input. It could be a ‘print view’ button that you can click to get a simplified version of the document which could be easily printed or even a way to set the theme for the page. Under the hoods what happens is usually that the links are pointing to a URL which had a ‘style=foo.xsl’ parameter in it. So that is the problem.

But why ?!?

Because the attacker can do whatever he wants. The XSLT allows full control over the page where it is used. You can just modify parts of the page to do some defacement or simply replace the whole body part with your evil content like barbies riding on pink unicorns.

I created a Proof-of-Concept application which can be downloaded from github. Let’s say that the application can be themed with XSL and the file name to use as stylesheet is always given in the URL. Hence to use the ‘pony’ theme you will be using the:

http://127.0.0.1:1337/?style=pony.xsl

And the result is this really nice page:

The attacker has already uploaded the malicious ‘attack.xsl’ to do an XSS against you. The ‘attack.xsl’ is the following:

<?xml version="1.0"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
  <html>
  <body bgcolor="black">
          <p style="color:white">all your base are belong to us</p>
    <script>alert("Boo")</script>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

This XSLT will match the whole document (/) and creates the HTML code with the JavaScript in the ‘body’. Hence every XML where this transformation is applied can be turned to a malicious HTML page.

You can see that the HTML was changed as well as a JavaScript was added.

To exploit this vulnerability the attacker can send the following link you:

http://<address>/?style=attack.xsl

The resulting page will be the following:
XSL POC
It can be a limitation if XSL files could only be used from the same domain, however generally there is some innocent file upload in that domain where you can upload your evil XSL and then you can use it to craft malicious URLs.

The solution

In Hungarian I would say that the solution is simple as a rod (I don’t know what would be the English equivalent, but you are welcome to comment): don’t allow users to define the XSLT. There is nothing to discuss here it is an internal thing which users shouldn’t access. I couldn’t imagine a situation where it would be really necessary.