My colleague brought my attention to a really interesting ‘feature’ of browsers. Namely that XHTML namespaces in an XML document will be rendered as XHTML instead of XML. That means that if you can some way control an XML that will be rendered by the target’s browser, then you can insert HTML and of course JavaScript code. So this feature widens an XML injection to an endless attack vector.

Let’s see a POC. I had a simple XML injection in this example (which I wrote and it doesn’t do anything else then returning an XML). First if I send innocent input it will simply return an XML and the browser will render it as an XML.

Test URL:


Response in browser:
Response containing XML

But if you request the following URL, then the response will be much more interesting:

http://localhost:1337/result?input=<a xmlns:b=''><b:body onload='alert(42)'/></a>

Response in browser:
Response with the malicious input rendered by the browser.

The returned XML with the JavaScript is the following:

    <info>this is just a normal xml</info>
    <you>You can write your staff here: <a xmlns:b="">
    <b:body onload="alert(42)"/>

The magic happens due to the XML namespace added to the <a> element. It tells the browser that under that element the XHTML namespace is used. So the browser tries to render it as XHTML and executes even our favourite pop-up window. This trick will also work when the malicious XML part is in an XML document and it is opened in a browser. I haven’t experimented with different browsers so I would just say that Firefox and Chrome support this feature.

Ok, so we have something here but why is it good for us and bad for everybody else? The answer is that it will increase the severity of an XML injection vulnerability. If you read the carnal0wnage blog then you must have seen the From LOW to PWNED series which introduce ways to use a low severity bug to exploit the system. This is something like that as well. Usually these XML injections would be low severity vulnerabilities because they are not that useful (since the browser won’t render the input) but this way they evolve to be critical vulnerabilities.

Last but not least here are some attack scenarios where this trick could be used:

  • The web app uses a JavaScript based UI which communicates using the XmlHttpRequest and XML. In this case the attacker could inject his malicious input somehow and if he can craft a URL or a Form that will get back the input in XML, then he could send it to his targets. When they open it the malicious code gets executed.
  • XML documents can be downloaded from the web app. If the attacker can manipulate these XMLs and the web app doesn’t mark the files as attachments hence letting the browser to render it, then the attacker can get his targets to download these files.
  • The attacker can send the malicious XML files directly to the target because most of the time XML files will be opened using a browser when ‘double-clicking’ them.

To finish up this post let’s see what can one do against these attacks. I know it sounds lame to suggest the same as for every other XSS and injection attacks, but still: validation and output escaping. If the attacker hadn’t injected into the XML in the first place, then this feature/trick would have been useless. So the moral today is to do validation and output escaping properly.