XML injection attacks are nasty little exploits invented by hackers to help them compromise systems hosting XML databases. This includes the kinds of things that come to mind when one thinks about traditional databases - detailed stores of information about anything from medicines to movies.
XML injection attacks are nasty little exploits invented by hackers to help them compromise systems hosting XML databases. This includes the kinds of things that come to mind when one thinks about traditional databases - detailed stores of information about anything from medicines to movies. Some XML datastores are also used to check for authorized users, so injecting new XML code into them can create new users that the host system will accept from that point forward.
For an attacker to implement an XML injection, there needs to be an application which relies on, or at least accesses, an XML database. Whenever that happens, and user input is not properly vetted, new XML code can be added to the datastore. Depending on the skill of the attacker, adding new XML code can do quite a lot of damage, or even provide access to the entire database.
As you read on, you might discover that XML injection is closely related to the SQL injection attacks that we previously covered. That's because even though they target different types of databases, they are extremely similar. And thankfully, the fixes are similar as well. Learning how to defeat one type of attack will put you well ahead of the game when working to prevent the other.
In this episode, we will learn:
XML injections are successful whenever an unauthorized user is able to write XML code and insert it into an existing XML database. This only requires two things to work: an application that relies on, or connects to, an XML database and an unsecured data pathway for the attacker to launch their attack.
XML injections are almost always successful if user input isn't sanitized or otherwise restricted before being sent to a server for processing. This can allow attackers to write their own code, or inject it, at the end of their normal query string. If successful, this tricks the server into executing the XML code, allowing it to add or delete records, or even reveal an entire database.
Hackers implement an XML injection attack by adding XML code to a normal query. This can be anything from a search field to a login page. It might even include things like cookies or headers.
For example, in a registration form, a user might add the following code after the username or password field:
In this example, a new user named John_Smith would be created with administrator access. At least the new user is employing good password density rules. Too bad they are actually an attacker.
Hackers don't necessarily need to always hit a home run like that to be successful with XML injections. By manipulating their queries and recording the various error messages that the server returns, they may be able to map out the structure of the XML database. And that information can be used to enhance other types of attacks.
The level of danger involved in an XML injection attack depends on what information is stored within the targeted XML database, or how that information is being used. For example, in the case of an XML database being used to authenticate users, an XML injection can give an attacker access to the system. It might even allow them to become an administrator on the targeted network, which of course is an extremely dangerous situation.
For XML injections levied against more traditional databases, the danger is in having that information stolen, having incorrect data added to the store, or possibly having good data overwritten. XML code is not very difficult to learn, and some of the commands can be extremely powerful, overwriting entire information fields or even displaying the contents of a datastore.
Generally, nobody builds a database unless the information stored there has value. Hackers know this, which is why they often target them. If that data includes things like personal information on employees or customers, having it compromised can lead to reputation loss, financial consequences, heavy fines or even lawsuits.
XML Injections are fairly common due to the low degree of difficulty in pulling one off, and the prevalence of XML databases. But these attacks have been around for a long time. As such, there are several ironclad fixes that will prevent them from ever executing.
One of the best methods for stopping the attacks is to design an application to only use precompiled XML queries. This limits the functionality of the queries to an authorized subset of activities. Anything that comes in with extra arguments or commands that don't match the precompiled query functions simply won't execute. If you don't want to be quite so restrictive, you can also use parameterization. This restricts user input to specific types of queries and data, for example only using integers. Anything that falls outside those parameters is considered invalid and forces the query to fail.
It's also a good idea to pair precompiled or parameterized queries with customized error messages. Instead of sending back the default, descriptive error messages from a failed query, applications should intercept those responses and replace them with a more generic message. Ideally, you will want to tell a user why the query failed, but not give them any information about the database itself. If you restrict those custom messages to just a few choices, hackers will not be able to compile any useful reconnaissance from failed queries.
XML injections were highly successful when they were first developed. But given how long ago that was, today we can easily construct defenses that can no longer be breached.
For further reading, you can take a look at the OWASP writeup on XML injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.