So for my first proper post, I will be delving into an extremely common website exploit: Structured Query Language Injection. First of all, what is SQL? According to Wikipedia, SQL is “a domain-specific language used in programming and designed for managing data held in a relational database management system, or for stream processing in a relational data stream management system.“
Basically it is a database manager that allows the admin of the website to embed queries into the back-end of a site so that it can, for example, add a new user to the members database in order for them to login, which could be:
GRANT CONNECT TO username IDENTIFIED BY password
Or something similar to that (it all depends on the database manager they are using). This particular query could be activated when a user entered their username and password into a register as a new user form.
Anyway, this helpful database manager can cause a site admin some difficulties – especially if text input fields are not sanitized properly (Sanitation means making sure there are no illegal characters in any inputted text, such as turning a single quote ‘ to a double quote ” to prevent any bad things from happening).
This is where SQLi (SQL Injection) comes into play. SQLi is the process of inserting (or injecting) SQL statements into the database, VIA text input fields.
But surely you can’t get a database to execute a command just by putting it in a username or password box and hitting enter?!
That’s exactly what you can do – just as long as the input is not sanitized. Before you have even started to try and inject SQL statements, you need to check if the site is actually vulnerable. To do this, simply input a single quote ‘ into the username box and then enter anything you want in the password box. When you hit login, if the site is vulnerable, an SQL error should be displayed, otherwise it will just display an error message that the username and password was incorrect. There are other (probably better) methods of checking for this, but the single quote is the most common. By the way, this doesn’t even need to be done with a login form either – you can test SQL injection by appending a single quote to the end of a URL (make sure ?id=# is present, where # is equal to a number, otherwise it won’t work) and if the site is vulnerable, you’ll get treated with an SQL error. Once you’ve found a vulnerable site, you can move onto the next step: injecting statements!
So, you’ve successfully identified a vulnerable site, but how do you go about injecting statements? Well lets use an example to showcase this.
Imagine that this is the login form for your vulnerable site. Whenever a user types in their username (myusername12) and password (mypassword12) and clicks Login, a query is sent to the SQL Database which in this case is:
SELECT FROM Users WHERE Username = "myusername12" AND Password = "mypassword12"
Now if the login details are correct, myusername12 will be successfully logged in, otherwise it will deny them.
Now an attacker does not have any login details for this particular site, but what they can do is input text that will allow them to dump all of the information from the database table Users. In this example, they can input ” or “”=”. This will dump all the information because “”=”” is always TRUE, and so the database will dump the data. The query will now look like this:
SELECT FROM Users WHERE Username = "" or ""="" AND Password = "" or ""=""
Both the Username and Password field are now TRUE, so the database will now return anything that is stored in the Users table! This method of SQLi is known as Union-Based SQLi, and is one of the many different methods, such as Blind SQL Injections, Error-Based Injections and Timed-Based Injections. If you want to learn about all these different methods and get some more information on SQL injections, have a look at https://www.owasp.org/index.php/SQL_Injection, they go into different scenarios and explain the inner workings of SQL. If you want to practice, you can test your skills against vulnerable applications such as DVWA, which was literally made to be hacked.
That’s all for this post, I hope you learnt something out of it and in the next post I might be having a look at System exploitation, rather than Web exploitation!