Coders Conquer Security: Share & Learn Series - XML Injections
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:
- How XML injections work
- Why they are so dangerous
- How you can put defenses in place to completely stop them.
How do Attackers Trigger XML Injections?
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:
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
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.
Why are XML Injections so Dangerous?
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.
Stopping XML Injection Attacks
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.
More Information about XML Injections
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.
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.
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoJaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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:
- How XML injections work
- Why they are so dangerous
- How you can put defenses in place to completely stop them.
How do Attackers Trigger XML Injections?
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:
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
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.
Why are XML Injections so Dangerous?
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.
Stopping XML Injection Attacks
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.
More Information about XML Injections
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.
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:
- How XML injections work
- Why they are so dangerous
- How you can put defenses in place to completely stop them.
How do Attackers Trigger XML Injections?
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:
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
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.
Why are XML Injections so Dangerous?
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.
Stopping XML Injection Attacks
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.
More Information about XML Injections
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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoJaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
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:
- How XML injections work
- Why they are so dangerous
- How you can put defenses in place to completely stop them.
How do Attackers Trigger XML Injections?
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:
<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>
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.
Why are XML Injections so Dangerous?
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.
Stopping XML Injection Attacks
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.
More Information about XML Injections
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.
Table of contents
Jaap Karan Singh is a Secure Coding Evangelist, Chief Singh and co-founder of Secure Code Warrior.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.