2

I have found a way of forcing a site to return content-type XML to the user's browser even though the content is HTML. The browser then interprets this site as XML and throws an error since the HTML contains Javascript that doesn't decode to valid XML. Different levels of information is returned by the main browsers, but FF shows me:

XML Parsing Error: not well-formed Location: http://www.example.com/return_xml

Line Number 30, Column 1: var y= (a && a.b ...

The second & symbol breaks the XML parser. What type of attacks could be executed from this (if any)?

My first thought was XXE but I believe browsers disable that by default. Does this sound like a non-vulnerability?

iso123
  • 95
  • 5

1 Answers1

2

By itself this is not a vulnerability. If rendering XML (valid or not) were somehow dangerous, browsers would not allow it in the first place.

Not being able to make it valid XML rules out XSS, as the content would have to be rendered for it to work. Besides, if there were an XSS vulnerability in the page, it would probably be exploitable even when rendering as HTML.

There is one attack that comes to mind, though: Reflected File Download. If you're able to modify both the end of the URL path and parts of the document content, you may be able to craft a link that causes the page to be downloaded with an "incorrect" file name extension such as .bat or .ps1. Running this file locally would execute a malicious script on the victims machine, e.g. to download malware.

This would not work in all browsers; Safari and IE8 seem to be the only ones that download XML files instead of attempting to render them. And even then the attack relies on the attacker being able to inject enough content to make the document a valid executable script in some language other than HTML or XML.

There's a good white paper on RFD (by Oren Hafif) here, including a bunch of details about different browser behaviours and potential ways of exploitation.

jupenur
  • 441
  • 3
  • 8