What is SQL injection?
SQL injection (SQLi) is an attack on a web application (among the most known along with XSS) that exploits a security vulnerability in a target software, in particular, it allows the attacker to do some operations on the vulnerable database.
On the basis of past experiences, this kind of attack can be disastrous to those who experience it.
Just to better understand let’s list what can lead to a potential SQLi
Dynamic SQL queries: This means that the user has a kind of control over the query and can insert some parameters. The general rule is that everything that can be determined at the design time has to be static. However, it’s not always possible, so this is the parameter with less control among the three.
Error revelation: Errors can give the attackers some extra information such as database or table names. Even in this case, we can rely on the general rule that, in a production environment, we must show ONLY the information the final user has to see.
Insufficient input validation: The application has to sanitize external inputs every time it receives them. Do always that and you will prevent a lot of trouble.
The combination of these elements could allow an attacker to execute malicious SQL statements that could manipulate data, compromise the security of the website, or even gain access to the server.
Here is the list of all the articles about SQL injection for quick navigation:
In-Band SQL injection
Blind SQL injection
Blind SQL injection: How To Hack DVWA With Python (Low Security)
Blind SQL Injection: How To Hack DVWA With Python (Medium Security)
Blind SQL Injection: How To Hack DVWA With Python (High Security)
What are the different types of SQLi?
Even if you can find online many different classifications of the SQLi vulnerability, it doesn’t really matter and they are all equivalent.
However, I want to show you the classification I prefer among the ones I found, and I’m sure it can help you to understand better.
Anyway before explaining that, could be useful to have a visual overview, so I prepared this essential schema:
Now we can go a bit deeper and see what this chart represents:
In-band SQLi: An in-band SQL injection is where the attacker is able to use the same channel to inject the malicious SQL code and relay the results of the code execution back.
Union-based It uses the UNION SQL operator that can merge multiple SELECT queries. It can be useful because allows getting data from tables that differ from the one to which the query belongs.
Error-based: As we discussed in the introduction an attacker can force some errors in order to get extra information from the DB.
Inferential (Blind) SQLi: In this case, the attacker sends his exploit and then analyzes the response. The name “Blind” is because the application doesn’t show information to the attacker but he has to infer them from the application’s behaviour.
Time-based The attacker crafts the payload making the application wait some seconds only if a particular condition is verified. What it has to do is just measure the response time and infer the data.
Boolean-Based: This attack takes advantage of an application behaviour depending on a condition. The result can let the attacker deduce some useful information.
Out-of-band SQLi: In this type of SQLi the attacker can use some out-of-band channel to exfiltrate data from the database or to execute arbitrary commands on the server. For example, the attacker can trigger some DNS or HTTP requests.
A general idea about the SQLi
Even if this is just an introductory article, I’d like to show you a practical example, in order to better solidify the fundamental concepts.
Let’s imagine a website that takes the unsanitized username and password from the login form and put it inside the query: something like this.
SELECT * FROM users WHERE username = '$username' AND password = '$password'
In this case, the attacker has complete control of the input and can insert a crafted password value in a way to make the query always True.
Let’s see how:
Imagine that the attacker inserts as a password the string shown below:
' OR 1=1 --
In some DBMS (Database Management Systems) like MariaDB and MySQL, everything to the right of the string “–“ is considered a comment.
So, the final query that the software passes to the DBMS is:
SELECT * FROM users WHERE username = '$username' AND password = '' OR 1=1 --'
The query above would return all rows from the “users” table since the WHERE clause would always evaluate to true. This would allow the user to log in without a valid password.
Probably it’s enough to have a general idea of what SQL injection is.
Just to stress the concept, the attacker can concatenate to the query whatever he wants like list private entries, guess passwords, drop tables, and much more, depending on the entity of the vulnerability.
How to prevent SQL injection?
There are a number of ways to prevent SQL Injection, including:
Parameterized queries: A parameterized query is a query in which applications use placeholders for one or more user input values.
Stored procedures: A stored procedure is a set of SQL statements that an application can execute on a database server.
White-list input validation: White-list input validation is a method of data validation. With this validation technique, the application can enter system-only data that meets certain criteria.
Escaping all user input: Input escaping is the process of transforming special characters in input so that the target system will interpret them literally.
Using an object-relational mapper (ORM): An object-relational mapper (ORM) is a code library that automates the transfer of data stored in relational database tables into objects. It usually provides a set of functions with prebuilt security checks. Some of the best-known ORMs are:
Using a Web Application Firewall: A web application firewall (WAF) is a type of firewall that filters traffic to and from a web application. It can run as a network appliance, server plugin, or service. A WAF inspects web traffic to and from a web application and filters out malicious traffic, so it can detect an SQLi.
How dangerous can it be?
In order to understand the potential damage of such vulnerability, we can just remember two of the most famous attacks that exploited SQLi.
The most harmful SQLi attack in history was the 2017 Equifax data breach, which affected 145 million people. The attackers were able to exploit a vulnerability in Equifax’s website to gain access to sensitive information including social security numbers, dates of birth, and addresses.
Another famous event was in 2015, the Ashley Madison data breach, in which hackers gained access to the personal information of over 30 million users of the Ashley Madison website. The data leaked included sensitive information such as user names, email addresses, and credit card numbers.
Conclusion
SQL injection is a serious security vulnerability that can lead to sensitive data being leaked or even servers being taken over. We have seen in the previous paragraph how dangerous it can be, so don’t underestimate that.
It is important to take the discussed measures to prevent SQLi, you cannot save on cybersecurity, the potential damages are enormous. So the advice is always to rely on a real professional in the field to put in place security measures.