- Exploitation of XXE vulnerability
- Mitigations for XXE vulnerability
- How Briksinfosec helps you?
- Curious to read our case study?
- Last but not the least
- You may be interested on
XML External Entity Attack happens when an application allows an input parameter to be XML or incorporated into XML, which is passed to an XML parser running with sufficient privileges to include external or system files.
Recently, there’s been an increase in the use of XML documents due to the growing use of the web services such as REST and SOAP API, which commonly uses XML to process the data.
XML has a feature to create entities dynamically. Some of the objects are predefined, and they’re referenced by using an ampersand (&) and a semicolon (;) at the end. However, XML also allows us to create custom entities, the most popular being the internal and external entities. Internal entities can be used to reference internal data and external entities to reference data from external sources.
Example for an Internal Entity:
In the first line, we have defined an entity “name” having a value “Brisk”. The block used to define the entities is known as the ‘DTD block’. Next, in the third line, you can see that we have referenced the entity “&name;”, which holds the value “Brisk.” In this way, we don’t have to input the name each time. All that we have to do is use a reference to the entity.
Example for an External Entity:
In the first line, in the DTD block, we have defined an external entity, which contains a link to an external resource. When this XML document is processed, it would request an external source and would replace values of all instances of “&name;” with the content of the external resource. If the content of the external resource is processed and displayed back to the user without proper validation, an attacker may be able to abuse the parser in conducting an XXE injection attack.
To find an XXE (XML External Entity) vulnerability, either the attacker or tester needs to inject XML characters in all input fields and observe if XML parsing errors gets generated.
Exploitation of XXE Vulnerability:
Use information disclosed in error messages to determine at what file path the XML parser is parsing. Also, try to load files that don’t exist to determine the operating system type and the path at which interpretation is taking place.
Let us consider a testing website (here I’m using OWASP Mutillidae application)
1.In the below image, the application has an XML parser input page.
2. Let’s try giving some XML inputs and check the response from the server.
3. After that, we can try to inject the XML inputs with multiple user-defined entities.
4. Now, we can try to include external data using <!Entity> section of XML input. The <!ENTITY> section of an XML document optionally defines external files to be included as a part of the XML document. Interestingly, these can even be files from the system parsing the XML.
Using the <!ENTITY> section of XML input, we can try to access local files like /etc/ passwd files of a Linux server.
5. Once we’ve given the above XML payload, we can get the password files details from the back-end Linux server.
6. Similarly, we can try to load the boot.ini files if the server is Windows operating system. We can do it by using an XML payload like below:
Mitigations for XXE injection attacks:
1. XML parser functions like ‘unmarshaller’ should have a secure configuration to prevent allowing external entities as a part of an incoming XML document input.
2.XML inputs should not be processed directly as java.io.File, java.io.inputstream.
Now-a-days, API applications are gaining significant traction and hence are predominantly being used in almost all the software firms. API applications use XML parser in the backend for processing the user’s inputs from the frontend/application. This XML parser is prone to XML external entity injection attacks when the user inputs aren’t properly sanitized. Hence, a complete security assessment that scrutinizes the entire attack surface of your applications is mandatory.
Cyber Quote On API Security:
How Briskinfosec helps you?
Briskinfosec performs an intense API security assessment on your applications and detects the presence of XML and other related vulnerabilities. If we find any such of those, we immediately take the required steps to eliminate them from your security environment. Further, we also secure your security perimeter by providing a perfect security assessment that’s strong enough to best resist even the most complicated and dreadful cyberthreats. Apropos of that, we provide you practical awareness with real time scenarios of how to remain alert against the threats.
Curious to read our case study?
Our stakeholder, one of the leading insurance service providers throughout the globe and also a potential leader in Wealth Management System (WMS), called us to perform a complete API security assessment. While assessing intensely, to much of our surprise, we figured out that many vulnerabilities including XXE were identified. We eliminated all those vulnerabilities and read out our case study to see the way we won against those secretly lurking threats.
Last but not the least:
Just imagine the kind of blessing play store offers for Android mobile users? It’s so useful to people by providing them all the apps they need to use, and people are so grateful to it by downloading and using the ones they wanted, at one single click. If Android mobiles were developed without it, the steps needed to download each and every legitimate app would’ve been too much time-consuming.
Similarly, we’ve seen people complaining to us that it’s so hard to gain all the significant cyberattacks that’ve happened worldwide, at ease. We then politely showed to them our Threatsploit Adversary reports that’s exclusively meant to satisfy such desires of people. They were blown away as they were able to catch sight on all the notorious cyberattacks that’ve globally happened. Why are you waiting for?
Read it and you’ll never hate it.