We want to start this lesson by suggesting you that XML injection has another name, which is SOAP injection. Although many vulnerability types and injection may sometimes feel very similar, they do have some of their special differences. Yet, their point stays the same, that is a fact. Let’s learn about the XML or SOAP injection!
XML Injection Description
How do these vulnerabilities appear? The most common thing when they arise is that the users’ inputs are usually inserted into a server-side XML doc, or even a SOAP message, and of course in an unsafe manner. When you hear the term XML meta characteristic, what is the first thought that comes to your mind? Vulnerability and danger, right? Well, sometimes it is possible to use them with a purpose to modify the whole structure which belongs to the XML which will be resulting. Of course, XML injection can be used in so many different ways. As always, it depends on the attacker’s purposes and desires. It can be possible to use it with a purpose to interfere with the app’s logic and also to get the access to the unauthorized actions. The worst thing would be breaking the sensitive data. I would like you to remember the fact that such vulnerability is most of the times very difficult to see. Remember this when I talk later about the fixation part of the issue.
XML Injection Impact
As I have already said, interfering with the app’s logic, gaining the access to the unauthorized parts and stealing the sensitive data would be the most important thing to know when it comes to XML’s impact. But, it must be something else, definitely… I am afraid that it could be something much worse, what do you think? Of course, there is more.
What happens actually during the process of the XML injection? The attacker here tries to inject some various types of the XML tags. He or she injects in the SOAP message. In that case, these two terms representing the same kind of the vulnerability are connected. Once the tags are injected in the SOAP message, it will modify the whole XML structure. What happens if this operation is successful? The result is almost always the execution of a restricted operation. What else? The security objects. These may be get violated in two different ways. The first one is called Control. Here, the attacker is doing the modification of payment data by violating the security objective. In the second case, we have access control. What else could mean that than unauthorized admin login? It has almost the same purpose as the first one.
Example of XML Injection
I would like to ”meet” you with this vulnerability from the best example ever! I will show it through the unmodified payment transaction and the modified one. You will realize how the attacker gains the access ones the SOAP message is executed. Let’s take a look!
-unmodified payment transaction:
..
<!–excerpt modified SOAP message –>
<!–excerpt unmodified SOAP message –>
<transaction>
<total>4000.00<total>
<credit_card_number>
123456789</credit_card_number><total>4000</total><credit_card_number>123456789
</credit_card_number>
<expiration>01012008</expiration>
</transaction>
..
And now, a modified transaction where the attacker pays the amount of $6.6 instead of $4000.00:
..
<!–excerpt modified SOAP message–>
<!–excerpt unmodified SOAP message–>
<transaction>
<total>4000.00<total>
<credit_card_number>
<!–Attack payload line below. If attack is executed successful, the <total> tag with its value gets overwritten by 6.6–>
123456789<credit_card_number><total>6.66</total><credit_card_number>123456789
</credit_card_number>
<expiration>01012008</expiration>
</transaction>
..
Recent Attacks of the XML Injection And Impact
As I have talked so much about various types of damages that this injection does, we can repeat it together to learn it better. Gaining the unauthorized access, reading or stealing the sensitive information, breaking into a bank account etc. I will describe you now the way it actually goes. First, I will tell you that the location of the attacker is some web service client. The attacked web service component would definitely be XML Parser. What else do we get here? We also have the web service’s components which are indirectly involved in such attack. Those are the arbitrary number of the intermediary web service, the receiving of the same web service, then we have schema validation, the signature verification, decryption, some other app’s specific processes and the app’s logic. So, the attacker knows very well what are the endpoints of the service. He or she also knows the metadata and with such knowledge, it is easy to reach the endpoint from its location.
How to Fix XML Injection
I have said earlier that such vulnerabilities may be hard to detect. What can we do then? First of all, you must be sure that you always review the app’s response. The second thing is that you should review its purpose which input that is relevant performs within that app’s functionality. In that case, you will find out if it is vulnerable.
What about the user input? Be sure that the app validates it too and sanitize it. It is a must before you have to incorporate it into the XML document or even in a SOAP message. You can also block some meta-characteristics such as < and >. It would be the best to replace them with some of the corresponding entities-&It, or >.
I think that we learned so much together. keep your accounts safe!