One way to get malicious data into an application is for the bad guys to put it there themselves. In this video, you’ll learn about data injections and how they can be used to control you and your data.
<< Previous Video: Buffer Overflows Next: Cross-site Scripting >>–>
The ideal operation of most applications is that they accept a certain kind of data, they perform a function on that input data, and they provide some output to you. You, as the end user should not be able to inject your own data into that application. But unfortunately, many applications are not written very well. They’re programmed badly, and because of that they don’t check to see the type of input going into the application. When this happens, you or anyone else would be able to inject their own code into the input of this application, and based on how the application is written, you may get a number of different outcomes.
Part of the challenge is with being able to stop this code injection is that there are so many different ways to get data into an application. You can see there’s HTML. There’s SQL. There’s XML. There’s LDAP. There’s many other data types as well to use as input into an application.
S-Q-L, or SQL, is Structured Query Language. It’s one of the most common languages used to retrieve information from a database. And because of this, It’s one of the most common ways to inject your own data into an application. If you can find a way to have your own requests go into the database, then you can effectively look through the entire database for information without technically having permission to do so. Obviously, the application shouldn’t allow this, but if the application isn’t written correctly, you might have more access to the database than anybody realizes.
It just so happens I have my own poorly written application that allows me to inject my own SQL information into the front end of this app. This comes from a series of poorly made applications called WebGoat. You can find this at the Open Web Application Security Project, or owasp.org.
This is the front-end to a database that is supposed to show me information about my credit cards but nobody else’s. Now if I use the credit card name of Smith, you can see that it provides me with a list of credit card information for John Smith. And if I’m John Smith, that’s the only information that I should have access to. But by simply changing the input, by adding a little bit of SQL code right in the front and clicking go, you can see that I have access to Jane, Jolly, Grumpy, Peter, Joseph.
I have a lot of information that I can find everywhere in this database. Obviously, this is not something I should be able to do. But because I’m able to perform a SQL injection right here in the web front end, I’m able to get a lot of information on the back end that I am not supposed to have access to. It’s this trust that the application and database have with each other that allow me to take advantage of this. And you can see now why SQL injections can be a significant vulnerability.
Obviously, SQL is just one way to get data into an application. There’s many other ways as well. One type of injection is an XML injection. It stands for Extensible Markup Language. It’s a very standard way to take data and put it into and out of an application. And by injecting our own information into the XML, we may be able to manipulate an application. A good application is obviously going to validate the XML. We’re looking for the poorly written application where we can put whatever we’d like into that XML and inject it into the application.
Another language we can use to inject our own data is LDAP. This is the Lightweight Directory Access Protocol. This allows us to retrieve information from these LDAP databases, very similar to what we saw with a SQL injection. So by using our own injection into the LDAP database, we’re able to see more information than normally we would have access to. You can see that these are significant vulnerabilities. By taking advantage of shortcomings in an application, we now have access to a wealth of data that normally would not be available to us.