Fending off XXE attacks in Mule

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Trust no one! Most security issues comes from assuming that no bad person is going to tamper with your input data. We usually pay more attention to it when processing the most common inputs, such as an HTTP request or some argument that’s going into an SQL query. But we usually don’t pay much attention to other types of resources that are also vulnerable to malicious thinking – such as an XML file.

External Entities are an XML feature which allow you to embedded an external source into your document. For example, let’s suppose that your application responds to queries using an XML schema, which contains a disclaimer footer. Your legal department is prone to changing the wording on it so it probably makes sense to take it from an external file, so that your templates (which are part of your deployed source code) are not modified. Such templates could look like this:

So far so good, this looks pretty harmless. The problem is, what happens if my application allows customization of that template? Or what happens if a developer in your organization was denied a raise and he wants payback by hacking your servers? In either case, a template like this could come to be:

Oh darn! Shadow file is not a nice one to expose. Ok ok, that would be discovered pretty soon and not many people would know what to do with a shadow file. There are other things I could do with this though, for example, re-routing all responses to my own servers so that I provide fake data which completely ruins your reputation and leads users to bad decisions:

As you can see the issue is pretty serious. You really can’t trust anyone, sometimes not even your source code.

The Horror


Yeah…. This can happen in Mule. Our XSLT transformer has this vulnerability and a XSLT template can fall for this trick… That was of course until Mule 3.5 when the problem was brought to our attention and we fixed it!

Since Mule 3.5.0, no XML transformer will allow external entities by default. But hey! What happens if I’m the guy doing a legitimate use of it to add a disclaimer footer?

In that case, you can always bring it back, but you have to explicitly do it, taking a conscious decision to trust the template you’re using. You can do that like this:

The acceptExternalEntities attribute is a boolean that defaults to false and specifies if external entities are to be allowed.

In short

XXE attacks are probably not the most common attack but definitively a serious thing. If you’re exposing XML content we strongly advise you to take a look at this whether you’re a Mule user or not. If you’re a Mule user and you’re using the XSLT transformer, then we suggest upgrading to Mule 3.5 and disallow XXE unless you’re absolutely sure about the integrity of your templates and developers. If you want to know more about XXE, check this cool OWASP article.

Hope you liked this. Thanks!

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Mariano Gonzalez

I first started working on the IT industry in 2001 and I've been working as software architect and team leader since 2006, mainly on BPM/ERP applications for industries in the agriculture, energy, government, IT, telecom and content management industries, serving roles of Team Leader and software architect. Since 2011, I also started to specialize in SaaS applications and integration on the Cloud. I have a strong orientation to both, software architecturing and design as for team management, I'm constantly looking for challenges that allows me to develop and increase my social and technical skills

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>