A SQL injection can provide an attacker with access to everything in your database. In this video, you’ll learn how a SQL injection is constructed and you’ll see a live demonstration of a SQL injection on a vulnerable application.
When using an application, there’s usually some type of authentication required. We have to put in a username, a password, and all of the data that we’re viewing is specific for our login. But what if an attacker was able to inject their own code into the communication going back and forth to the server, and somehow circumvent this authentication process to gain access to all of the data that’s in the database?
One of the common techniques for this type of attack is a SQL injection. Most of the time, an application should be doing some type of validation of the input and making sure that nothing malicious is making its way into the application itself. But if an application developer is not spending a lot of time on input validation, or they’re not doing any type of validation, this might leave this application susceptible to a SQL injection attack.
This is not the only type of data that could be injected to gain access to the internals of an application. An attacker might use HTML, XML, LDAP, or any number of methods to be able to circumvent the security features of that app. SQL or sequel is the Structured Query Language. This is a very common language used to access information contained in a relational database. If you’re using MySQL, Microsoft SQL Server, or any number of SQL-based databases, they will all use a similar language to access that data.
A SQL injection allows us to put our own SQL queries into this application. This is something that should never occur, but because of the way the application is built, it allows us to circumvent the security and gain immediate access to all of that database information. The reason that we have a username, password, or some type of authentication is to protect this data in the database. A SQL injection bypasses all of those protections, and effectively gives someone full access to all of the data in that system.
If we were to look at an application, you might be able to find some SQL code in the application itself. And I have an example here, which is select asterisk from users where name equals, and then a variable is installed there as username. This means that we’re going to select information that is in a database. We’re going to select everything from a table named users. And we’re looking for a specific username in this example. And it’s the name that is contained within that variable as part of the application.
If we were to see this in use, the actual query would look something like this. Select asterisk from users where name equals professor. That is a very common SQL query, and it’s one that is going to request the database to provide all of the records where the username equals the word “professor.” What we’re going to do is to inject our own code into this query. In this case, we’re injecting everything that’s listed here in purple.
So instead of having this select command the way it was, we’re going to add additional information onto the select command, specifically an apostrophe, the word “or,” an apostrophe, 1, apostrophe equals apostrophe 1. This jumble of apostrophes, and letters and numbers changes this query. So instead of simply looking for one username called Professor, we’re looking for any username called Professor or anywhere where the number 1 might equal the number 1.
Obviously, the number 1 does equal the number 1, which means this part of the query means that we’re going to look for any name that might be in the database and return that information to the user. Even if the user does not have access to other parts of the database, this little bit of injected data effectively circumvents any type of security that may already exist. That single bit of injected code now gives the attacker full access to the database, where they can view the data, modify the data, or delete data from that database.
Let’s try a SQL injection into an application that has intentionally been written to be susceptible to a SQL injection. This is an exercise within WebGoat, which is an intentionally vulnerable set of applications and examples. In this example, there is an input for an employee name and an authentication access number. This code is one that is very similar to a password. Normally, we would type in our username and the authentication tan.
The username and the tan that would be used for normal user are listed here on the screen. So the username is Smith, and the tan is 3SL99A. This is the normal username and password someone might use to gain access to this application. And if we submit that, we can see that we are logged in with that username, and we can see their user ID, the department associated with this user, their salary, and of course, you can see their authentication information, as well.
But the attacker doesn’t want access to the single user’s data. They want access to all data inside of this system. So let’s reset this page. I’m going to refresh it, so we’re back to where we started. And now we can see that we can put in our SQL injection right here on this employee name line. We’re not using a legitimate employee name. We’re not putting in a password. We’re simply putting in apostrophe, or, 1 equals 1, semicolon, dash, dash.
And if we choose the option to get that department, it lists out all of the records in this database, so we can see all of the user IDs, everyone’s name, the department that they’re in, and we can see the salary for everybody in the organization, along with the authentication information for each one of these usernames. Obviously, this information should not be accessible to us, but because we were able to successfully use a SQL injection, we circumvented all the security and gained full access to the database.