In this article, we will talk about the special type of Server-side Request Forgery attack, which is also known as SSRF. I will introduce you how XML external entity injection works and what are the damages that it causes. The most important thing for you is to understand its paths and also to be prepared to recognize it. Later on, you will find out how to prevent it or fix it. Stay concentrated, this is a very important lesson!
XML External Entity Injection Description
These vulnerabilities seem to arise always when the app’s processes under the user’s supplied XML documents. Also, it is most common here that those are too enabling the references to some external resources. If we take a closer look, we will easily realize, that by default, XML parsers are typically supporting the external references. The fact that they are rarely required during the normal usage doesn’t change that. So, what happens here is that the external entities are able to reference such files on the server’s filesystem. Once that happens, such feature can easily be exploited allowing the retrieval of the arbitrary files. It may happen too that it denies the service. It does it by causing the server itself to read from a file which is a /dev/random.
XML External Entity Injection Impact
What can the external entities do, besides all that I have mentioned above? Unfortunately, there are more issues which the XML can cause that described. It may happen that those entities also start referencing the network resources, and all that through the HTTP protocol. Once the server is vulnerable, it will be used by the attackers as a proxy, and via it, they will be able to send further requests to other systems. The attacker then causes the app’s server to attack other systems I’ve mentioned by submitting some suitable payloads. Those that are vulnerable are public third-party systems, as you have probably heard so much about them already. Also, the internal systems within the same organization will be easily impacted by this injection. What about the services which are always available on the loopback adapter? They are on the app’s server, so the answer is obvious. This injection is highly vulnerable.
Example Of XML External Entity Injection
We will now take a look at the example. It may seem initially harmless, but you need to understand that XML entities may be used by the attacker with a purpose to cause the total Denial of Service attack. It can be done by embedding the entities, and within entities, and again within entities. That is why these attacks are also known as Billion Laughs Attacks. Sounds frightening, right? Let’s see how the request and the response look like!
Request:
POST http://example.com/xml HTTP/1.1
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY bar ”World ”>
<!ENTITY t1 ”&bar;&bar;”>
<!ENTITY t2 ”&t1;&t1;&t1;&t1;”>
<!ENTITY t3 ”&t2;&t2;&t2;&t2;&t2;”>
]>
<foo>
Hello &t3;
<Ifoo>
The response looks like this (a little bit frightening, if I may admit):
HTTP/1.0 200 OK
Hello World World World World World World World
World World World World World World World World
World World World World World World World World
World World World World World World World World
World World World World World World World
Recent Attacks Of XML External Entity Injection And Impact
Besides all that I have talked about, and the creepy Billion Laughs Attacks, there can be done so much more damage than declaring the elements, attributes or text. But I am sure that you have realized that already. The XML injections are mostly sent thought the documents which don’t look vulnerable. It is done either by specifying a set of a whole markup declaration which is designed to define a document type. It can be done through an XML schema (XSD) or by DTD, Data Type Definition. Most of the times you need to remember that the second option is mostly used in the attacks.
How To Fix XML External Entity Injection
Here we are, understood how this high-risk injection works and learned what it does and how much damage it can do. Now, we will learn how to fight against it! First of all, you must be sure that the parsers that are used all the time for processing the XML from the untrusted sources stay configured with a purpose to disable a process of all incoming external and vulnerable resources. It will help you to escape from plenty of attacks related to XML injection. Also, always consult the documentation for your own XML parsing library, because in that case, you will be able to determine how to achieve what we have recommended. I would highly recommend you to disable all of the DOCTYPE tags and to use the input validation to block it if it appeared.
Have you ever wondered how many different kinds of cyber vulnerabilities exist? Remember yourself when you were younger, thinking like:”Oh no, a virus!” And the story ended like that, right? Now, we are understanding the attacker’s brain and once you understand how it works, you will know how to protect yourself! Stay informed!