The number 1 threat according to the owasp top 10 list are injections. Among them is the SQL Injection.
An SQL Injection abuses bad sanitation to inject malicious SQL code into a web server or web application.
By injecting SQL code via a website, an attacker can read, edit and delete everything in a database. Databases hold all the information for a specific website or even an entire company. So this is a very dangerous attack.
Usually, a database consists of multiple tables which have relations to each other.
To perform an SQL Injection the attacker has to find a place to input something on a website (like a login form or similar) and inject SQL code. But how? And why?
The first part of SQL Injection is SQL. It stands for Structured Query Language and is used to manipulate, create and delete everything in a database.
In a well-designed database, different users have access to different parts of it. This can prevent one part of the application to be hacked by another part (like reading all usernames and passwords from the search function).
Like most languages, you can also use comments (
--), semicolons and other fancy stuff to organize your code.
In the simplest form, SQL is used to retrieve data from a table. For example, if you want to check if a user with the given password exists:
SELECT id, name FROM users WHERE password="password" AND name="name";
Which is how most login forms work (simplified).
The second part of an SQL Injection is the injection itself. Let’s understand how a login form works. It is a classic example of an SQL Injection.
In a standard login form, you can enter your username/email and password and click on “login”. But what happens when you click on that button?
Your data is sent to the back-end (the server) and processed by it. Which in term means that it will be run on the database server as a privileged user that has access to that data.
An attacker might not have direct access to the database but can gain it via the website.
Let’s say you enter your name “Jerry” and the password “Morty” into the Log- In Form. What happens in the back-end?
The following statement is executed on the database:
SELECT id, name FROM users WHERE name="Jerry" AND password="Morty";
This table returns a user with the name Jerry and the password Morty.
Doesn’t look so interesting. But this was just normal input. How about some malicious input?
Let’s say for example you would enter something like
into the name field, how would it look like? Try it down below:
It should look something like
[..] WHERE name ="Jerry" -- " AND password="";
Woah! You know what that means? It means that you changed the statement that will run in the database. It will now return a user from the database that has the username Jerry, no matter what the password is!
How to prevent SQL Injection
The simplest way to prevent this injection is to sanitize the input (and output). This is valid for most injections btw.
Usually, a developer will use something like Java or a Framework that will already offer a protection: Prepared Statements.
They will already escape characters like
", --,and other possibly harmful ones.
Examples And Further Explanation
I’ve created a video playlist where I explain (step by step) how you can perform an SQL Injection attack.
And if you’re still thristy for some more examples, check out the next playlist. It contains multiple hacking challenges that I solved, where you have to perform an SQL Injection (And more explanations):