SQL Injection – CompTIA A+ 220-1102 – 2.4

A poorly written application can allow users to inject their own code into the app. In this video, you’ll learn about SQL injection and view a demonstration of a SQL injection in a web-based application.

When you use an application, it’s common for us to provide input to the application. The application processes that input and then provides us with the results of our request. During this process, there’s code that happens behind the scenes to send that request to an application server or database server. There’s processing that occurs on the back end. And then finally, that information is sent back to our browser.

During that process of sending the data and receiving the data, there is the potential to manipulate the data request on the fly. We refer to this as code injection because we are adding our own code to this application to be processed. Normally, this would never be allowed. You certainly would not want anyone to be able to add their own code to a particular application. And this usually occurs because of bad programming or the application is not properly handling the input that we’re providing to the app.

The term code injection is a very broad term that describes a number of different vulnerabilities that might include different types of code. For example, you could inject HTML, SQL, XML, LDAP, and other code types. In this video, let’s look at a SQL injection and see how we’re able to manipulate the code of an application to have it perform functions that are outside the scope of the app.

SQL or SQL stands for Structured Query Language. It’s a very standard way to communicate with the database and receive information from that database. If you’re performing a SQL injection, then you’re sending some information into the application that will manipulate the data inside of the database and provide you with information that normally you would not have access to. Imagine having a database that is full of sensitive information and normally you would not have access to that sensitive information.

But changing one piece of the input that you’re putting into the application could potentially allow you access to the entire database. Let’s bring up an application and perform a SQL injection to see how this might work. I’m going to use an application that has specifically designed to be vulnerable so that I can perform this SQL injection. This is an application called Web Goat that was created as a training tool to help you understand how vulnerabilities might happen with these applications.

You can use this on your own system by going to any search engine and typing in Web Goat download. Let’s perform a SQL injection we’re on a screen that gives us an example of performing this SQL injection. And this application is for an employee. The HR department within your organization may be responsible for keeping track of your salary, how many days off you may have accumulated, and other information that’s personal to your employment.

Let’s perform a normal query to see what it might look like from the perspective of a user. There’s a user in here with the last name of Smith, and they have an authorization number that can be used to log in to this system of 3SL99A. That’s effectively the password that allows you access. And if I click Get Department, it provides us with information on the user ID, first name, last name, the department, how much salary this person makes, and then their authorization code.

This is certainly the type of information that a single employee might have to be able to manage their salary or look at other information about their employment. But what if you had a way to circumvent the security of this application and suddenly see all of the information for all of the employees in the organization? You can do that by making one change using SQL injection. I’m going to use the same application with the same employee name and the same authentication code.

But I’m going to add some additional information to the end of the authentication code effectively injecting my own code into this application. So at the end of the authentication code of 3SLA99, I’m going to include an apostrophe, the word “or,” apostrophe, 1, apostrophe equals apostrophe 1. And although this seems a bit cryptic, this is SQL code that allows me to perform a query to the database. This effectively says find every instance where the authentication code equals the one I put in or any authentication code where 1 equals 1.

In the world of SQL software, 1 equals 1 is simply a message saying find everything that is true or every entry that happens to be in the database. So we’re effectively saying, show me all of the instances where this authentication code is valid or any authentication code is valid. And if we click Get department, we will now suddenly have a list of all of the employees of the company. We’ll know everyone’s user ID, everyone’s department, and, of course, everyone’s salary. You can see how easy it is for a piece of software to be susceptible to this type of injection attack. So you want to be sure that any software you’re using has always been checked for any type of inputs and is not susceptible to a SQL injection.