Code injection is a relatively easy attack vector to exploit. In this video, you’ll learn about SQL injections and how they are used by attackers to gain access to our data.
A code injection attack is a very common application attack where the attacker will put their own code into information that is input into the application. This obviously is an attack that should not be allowed in the application, but the application developers have to put checks into their code to prevent any type of unnecessary or unwanted application data being injected during the normal input into the app.
And you’ll hear about many different kinds of code injections. There is HTML code injection, SQL injections, XML injections, and others. Let’s look at one specific type of code injection. This is the SQL injection. SQL stands for Structured Query Language. It’s probably the most popular way to have an application interact with a database.
The way your application is supposed to work is that it will take information that you’re inputting into the application and use that information as queries into the database. A SQL injection, or SQLi, allows an attacker to put their own requests into this query that’s being made to the database. Obviously, the application should not be allowing this, but if an application doesn’t have the proper checks, then you can send anything you’d like to the database.
This is also often not a difficult vulnerability to exploit. You can do this within the browser that’s being used as the front end to the application and simply inject your data into the input fields that are already in that application. If you were to look behind the scenes at the code that’s communicating between your browser and the web server and database server, you would see something like this.
This is website code that does a SELECT asterisk FROM users WHERE name equals, and then everything in red is added by the application. In this particular query, you’re asking the database to select all information where a particular username equals a username that you’re putting into the app. So if you’re using an application where you’re putting in a name to search, such as the name Professor, the code that’s sent to the database says select everything from users where name equals Professor.
Now, normally, that would be the end of the transaction. But if this application is vulnerable to code injection, we can add our own SQL code into this query. So instead of just asking for a username, we would SELECT asterisk from users WHERE name equals Professor or 1 equals 1. This is a common form to be able to ask for everything that may be in the database because, obviously, 1 does equal 1.
And if you ever see any code being sent to a database where the request is asking if 1 equals 1, it’s very likely that you’ve run into a SQL injection. You can also see how easy it is to exploit this vulnerability. All you have to do is add additional code into the input line of the application. There’s no additional software that has to be written. You don’t have to somehow make a user click a piece of information. All you have to do is add additional code into the app.
This type of exploit can also provide you with a great deal of control of the data in that database. Because you’re circumventing the security of this database, you effectively now have complete control to the data inside. You can view everything that’s in the database, or delete everything that’s in the database, or simply make changes or bring the database down so that nobody can access the data.
Let’s look at an example of SQL injection. I’m using an application that has been specifically written to be vulnerable. It’s part of a series of applications called webgoat. And you can find it at webgoat.org. In this case, we have two pieces of information we’re going to add to the application, an employee name, which is Smith, and a transaction authentication number, which is something like a password. And we’re going to add that into that field for 3SL99A.
So if you were normally logging in with your name and your password, you can click Get Department, and it shows you the department information for that particular query. Notice that this query is limited to the name Smith and to this specific transaction authentication number. Now let’s use SQL injection to view all of the information that’s inside of the database. We’ll use the same username and the same transaction authentication number, but I’m going to include additional injected code into this field.
We’ll put in apostrophe or apostrophe 1 apostrophe equals apostrophe 1. So we’re adding in that additional code that says, look for everything where the transaction authentication number is 3SL99A or any place where 1 happens to equal 1. And since 1 does equal 1, when we Get Department, it provides us with everything that’s in the database. And we effectively now have complete control of all of this data.