SQL Injection, XML Injection, and LDAP Injection – CompTIA Security+ SY0-401: 3.5

Database security can sometimes be circumvented by poorly designed software. In this video, you’ll learn how SQL injection, XML injection, and LDAP injection can get data from the most secure databases.

<< Previous Video: Cross-site ScriptingNext: Directory Traversal and Command Injection >>

Code injection is a type of attack where you’re taking your own code into your own exploit and your embedding it within an existing data stream. You may be able to do that from a website. You may be able to do that by manipulating packets as they’re going by. There’s many different tools to be able to do that. And there’s many different types of code that you can use and inject into a stream of data. This is usually enabled or it’s something that is available as an exploit because somebody’s done a bad job of coding the program. Normally applications should look at what people are using as input and clean it up and make sure that people don’t take advantage of these injection type vulnerabilities. But if you’re doing filtering and you’re properly handling the input and the output from an application, you shouldn’t be able to inject your own type of information into the middle of that.

There’s so many different data types. People do data injection of HTML, of SQL traffic, XML, LDAP. There’s many different ways to put your own little piece of information within a stream to try to get around some of the security that might be there. When we think about large enterprise databases, we usually think about SQL based databases. This is SQL. The stands for structured query language. This is a very common language that many of the largest databases out there will use. You’ll see this in relational database management systems. It’s a very, very common database language and it’s very powerful database language, which is why we see it in some of these very, very large databases.

Well, one of the things you can do is inject your own SQL code into some of these streams and you end up having the SQL injection. You’re modifying the actual SQL requests that are being made to a database. And you’re doing it through a web front end. Usually you don’t have direct access to the database. You talk to a web server behind the scenes, the web server then talks to the SQL database. But if I can give the web browser in front of me bad information to give to the web server, which then gives bad information to the SQL Server, I can then get information out of the database that perhaps the developer never intended me to be able to do.

If you look at SQL injection it’s very prevalent, but there’s other types of injection as well. For instance XML injection. XML stands for extensible markup language. It’s a very common format that’s used these days to transfer information between point A and point B. We can store information, transfer information, and it’s a standard format. Because it’s a standard format there’s an opportunity here to inject my own type of XML requests inside of that to be able to change things however I would like to change them on that web server. Good applications will validate this XML, badly or poorly programmed applications will not. And that’s an opportunity for the bad guy to get into this XML to be able to have your application do things that perhaps you were not intending that application to do.

Another type of code that susceptible to injection, we see this often, is LDAP. LDAP stands for lightweight directory access protocol. It was actually protocol created a long time ago by the telephone companies, they need an easy way to access user names, to access your first name, last name, your address, and your phone number, and it needed to be in a massive database. And that’s where, really, directory access protocol came from. What the lightweight directory access protocol is what we’ve now used on our computer systems these days and generally you see this as name services somewhere but other databases will also use this LDAP protocol as well. So if I can craft my own LDAP messages and insert them inside of an LDAP stream, I may be able to get around a poorly programmed application.

Let’s perform some SQL injection that’s going to allow me to login to an administrator’s account without having the administrator’s password. That obviously would be a pretty insecure system, and indeed this one we’re using absolutely is. This is called WebGoat, these are a series of very, very vulnerable web applications. You can download WebGoat from the open web application security project that’s at www.owasp.org

This is a human resources app and what I want to do is not login as an employee, I want to login as Neville, who is the administrator. But to be able to do that, I need to inject information into the data stream. And I’m going to use an add on in this Firefox that I’m using. It’s an add on that you can download and try called Tamper Data. It allows me to modify information on the screen. Change the way this data is being seen on the screen. I’m going to make this window a little bit smaller so we can see what’s going on.

What it allows me to do is as data goes to the web server I can stop it, modify the data, and then send it on its way. And we can actually do the reverse in the other direction if we wanted to. I’m going to turn on the tampering, I’m going to start to tamper. Which means any time I send information to a web server it’s going to ask if I want to change it. So I’m not even going to type in a password for Neville, I’m just going to hit log on and tamper says, would you like to continue tampering? Will absolutely, yes, I would. Because as part of this information in the header and parameters that are sent to the web server in the password field I’m going to perform some SQL injection. I’m going to type in some SQL code here that is going to get around the very, very bad programming that is on this particular computer. So there’s the SQL code that I have in place and when I click OK it’s going to continue with the tampering.

And if you look, I am now logged in as Neville with full access to everybody’s profiles. It is remarkable and quite powerful, this SQL injection. And that’s why when the SQL injection problems occur, they’re usually quite devastating because they provide so much access to the database and usually it’s information that you don’t want the bad guys to be able to see.