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.
But if you request the following URL, then the response will be much more interesting:
http://localhost:1337/result?input=<a xmlns:b='http://www.w3.org/1999/xhtml'><b:body onload='alert(42)'/></a>
<xml> <info>this is just a normal xml</info> <you>You can write your staff here: <a xmlns:b="http://www.w3.org/1999/xhtml"> <b:body onload="alert(42)"/> </a> </you> </xml>
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:
- 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.