Contemporary applications and websites often operate on a lot of data that are stored in databases. It is important for developers to ensure that queries to a database are sent securely to prevent possible confidential information theft, modification, or deletion. The most common databases are relational databases. They use SQL to manage data.
In this topic, we will discuss SQL injection vulnerabilities that can affect any application using relational databases. You will also learn how you can protect your project from SQL injection attacks.
What is SQL injection?
SQL injection (SQLi) is a web security vulnerability that allows an attacker to execute arbitrary SQL queries on the database. This occurs because the data entered by the hacker is mistaken for code by the SQL interpreter.
A SQL injection attack, in its simplest form, uses data that the user enters. If input forms in a web application pass user data to databases for processing, bypassing filters, an attacker can find this flaw and take advantage of it.
There are other approaches to SQL injection. For example, requests can be injected via HTTP headers. Or an attacker can go the other way by modifying cookies to inject malicious code into the database.
Usually, the result of an SQL injection attack can be observed immediately after the user enters the malicious data. However, there are also second-order SQL injections. They can remain inactive for a long time. There are situations where one part of the application is protected from SQL injection. It receives the SQL query and saves it in the database. However, that query is used by another part of the application which is not protected against SQL injection. Comments of any form are a typical example of second-order SQL injection. Attackers can inject comments in a blog or a site with malicious code. This comment is stored in a database and displayed to all other users later on. This malicious code will be executed when the data is incorporated into SQL queries while being displayed in the comment section.
SQLi attack example
To have an understanding of how SQL injection attacks work, consider a simple example. Suppose you have a form on a website, where a user has to enter their email and password.
When data is entered into the form, it is sent to the server and a SQL query is executed. If this query returns results, it means that the user data is correct and is logged into the site. The query looks like this:
SELECT * FROM users
WHERE email = 'myemail' AND password = 'mypassword'
The hacker attempts to log into another person's account. To do this, they manipulate the SQL expression so that the query will return all user emails, and the passwords would be ignored.
Namely, they write a random piece of string instead of an email, then put a single quote ('). The single quote here is interpreted as the end of input data. After which the input looks as if it is complete. Then they write an OR 1=1 condition so that the database would return all of the users' emails in the table. And, so that the database can ignore everything that comes after their query, they put the characters --. These characters are used for commenting in SQL. Instead of a password, the hacker entered another random piece of string.
Eventually, when the hacker clicked "Log in", the database got this instead of the expected query:
SELECT * FROM users
WHERE email = 'randomdata' OR 1=1--' AND password = 'randomdata'
The first part of this query returned all existing users since the expression 1=1 is always true. The second part of the query was ignored because of --, after which any subsequent text is interpreted as a comment.
Since this query was scored as successful, the hacker was able to log in to the account of the person whose email was first in the database.
Detecting SQLi vulnerability
There are multiple ways of detecting SQLi vulnerabilities:
- The easiest option is to enter symbols such as single quotes (
'), double quotes (") or semicolons (;) in the field for entering user data. And then observe how the web application reacts to them. - You can also enter logical queries (for example,
OR 1=1orOR 1=2). - Try entering queries that create a time delay.
Fortunately, it is not necessary to manually check your applications for vulnerabilities. There are many programs available that can help detect web security problems. Try them if manual testing is not an option for you.
Preventing SQL injection attacks
SQL injection attacks are possible due to incorrect processing of input data by the application. As we discussed in the introduction, this allows hackers to leak, change, or delete data contained in the database. The purpose of SQL injection attacks can also be to steal user credentials or to give the attacker administrative privileges on the database.
Let's take a look at how you can protect your web application from this type of attack:
- Validate user input. Check that it is valid, and format it accordingly. Escape user-supplied input, so that the DBMS does not consider the user input data as SQL statements.
- Use the latest versions of the development environment and language, as a rule, they protect against SQLi.
- Make sure that users don't see error messages that leak sensitive information about the inner workings of the application. Certainly, such alerts are useful during development. But if a hacker sees a database error alert, they can better understand the structure of the database and use that knowledge for their benefit.
- Do not use accounts with full rights to connect to the database, it is better to limit the rights. Try to use specially created users with limited privileges. This can minimize the impact of an SQL injection attack.
Conclusion
SQL injection attacks are one of the most common ways of hacking applications that use relational databases. They are based on introducing additional commands into SQL queries. It's important to check user input in your web application to eliminate or minimize the risk of SQLi attacks. In this topic, we've also covered other tips to help protect the project you're working on. Follow them and your data will be safe.