AdobeStock_78212150.jpeg

XML eXternal Entity injection (XXE) is an injection attack that occurs when untrusted XML input referencing an external entity is processed by a weakly configured XML parser. This attack may lead to denial of service, Server Side Request Forgery (SSRF), confidential data disclosure, and other negative impacts.  Rather than grouping XXE injection with other injection vulnerabilities (A1), OWASP decided to single this one and give it the number four spot (A4). 

Want to learn more about XXE and how to protect against it, register for our upcoming webinar:

[Webinar] The OWASP Top Ten 2017 - Let's Cut to The Chase on Wed., FEB 7th, at  1PM EST. Save Your Seat!

XXE  typically emerges as a result of developers being unaware that whatever XML parser they are using has XXE support enabled by default and this happens particularly frequently in Java applications. That is why it is such a prevalent vulnerability - all the Java back-ends and web apps that handle XML are at risk of this vulnerability unless the developers disable XXE explicitly. Other languages/platforms are similarly affected as well.

XXE are basically requests to load some kind of additional information from the system and sometimes even invoke system commands or execute some kind of functionality, like sending emails (this depends on how the target system is configured). The way the attack works is that attackers will insert XXE strings into XML data that will be processed by the application. Most common impact is the attacker being able to read files on the target system, but sometimes commands can be executed or files on other systems on the internal network can be read.

The way to prevent XXE injection in general is to just disable XXE for the XML parser programmatically, which is fairly easy to do. My professional opinion is that XXE should be disabled by default unless explicitly enabled. Relatively few applications actually use XXE as intended and in any case they should not be present in data supplied by the users. If developers follow this standard practice, then hopefully we won’t see this vulnerability type in the next OWASP Top Ten release