Security testing: SQL injections

In this article, we will look at the basic concepts of SQL injection, discuss some common examples, and you will also learn how to find and use different vulnerability types and how to prevent SQL injection.

Basic concepts 

Code injections (SQL, PHP, ASP, etc.) are a type of vulnerability that can lead to the possibility of executing code to access system resources, hack personal data, or the corruption of software. 

Structured Query Language Injection is one of the most frequently used hacking methods that interacts with databases. Basically, the essence of this method is to inject any random SQL code into the data (transmitted using GET and POST requests). Any resource that accepts and executes such injections is vulnerable and, therefore, the database can be manipulated in any way.

Causes of the introduction

SQL injection vulnerabilities occur when user-controlled data is insecurely included in database queries. An attacker can provide specially crafted input to break out of the context of the data in which it is displayed and interfere with the structure of the surrounding query.

SQL injection frequently can be achieved through a number of malicious attacks, including reading or corrupting critical application data, interfering with application logic, upgrading database privileges, and gaining control over the database server.

What are the consequences of a successful SQL injection attack?

A successful SQL injection attack can lead to unauthorized access to sensitive data (for example, passwords, credit cards, or other personal user information). There have been many major data breaches in recent years that have resulted from SQL injection attacks, causing reputational damage and fines from regulatory authorities. In some cases, an attacker can establish a permanent channel into an organization's systems, resulting in a long-term vulnerability that may remain unnoticed for a long period of time.

Here are some popular examples of SQL implementation:

• obtaining hidden data, where the SQL query is changed in order to get additional results;
• undermining the application logic, where the query is changed in order to disrupt the logic of the application;
• UNION attacks, which allow retrieving data from different database tables;
• database exploration, during which information about the version and structure of the database is extracted;
• blind SQL injection, when the query results are not returned in the responses of the application.

Let's look at a specific example based on the UNION attack.

This attack type is possible when SQL query results are returned in the application's responses. An attacker using SQL injection can get additional data from other tables in the database. The UNION statement allows running an additional SELECT query and adding the results to the original query.

For example, the application runs a query on the information about the availability of gift cards in the «Gifts» section:

SELECT name, description FROM products WHERE category = 'Gifts'

The attacker adds additional request to obtain user data:

'UNION SELECT username, password FROM users--

The server of the application processes the request and then sends the following request to the database:

SELECT name, description FROM products WHERE category = 'Gifts' UNION SELECT username, password FROM users--

This will result in the attacker receiving not only the name and description of the products but also information such as usernames and passwords.

How to detect SQL injection vulnerabilities?

Most SQL injection vulnerabilities can be detected quickly and accurately by various web vulnerability scanners ( for example: Burp Suite, and OWASP ZAP).

SQL injection can also be manually detected by using a systematic set of tests on every entry point into the application. Normally, this includes:

• sending the single quote character ' and searching for errors or other abnormalities;
• Sending some specific SQL syntaxes that evaluate the basic values of the entry point and looking for systematic differences in the received application responses;
• sending logical conditions, such as OR 1 and 1 і OR 1 = 2, and searching for differences in the responses of the application.
• sending useful data for triggering time delays in SQL queries and searching for differences in the time required for response.

Protective measures against SQL injections

It is quite easy to avoid this problem. All you need to do is to check the data placed in the queries with a simple processor. It is necessary to separate data from commands and queries, and there are several ways to do this:

1. Use a secure API that prevents the use of an interpreter or provides a parameterized interface. It is possible to use object-relational mapping (ORM) tools.
2. Implementation of white lists on the server to check incoming data. Of course, this method will not provide absolute protection, because many programs use special characters (for example, in text areas or APIs for mobile applications).
3. Also, you must implement character escaping for other dynamic queries using the appropriate syntax for the interpreter. Note: SQL structure elements, such as table or column names, cannot be escaped, therefore using names provided by users is dangerous. This is a common problem among reporting platforms.
4. Be sure to use SQL controls in your queries to prevent data leaks.

There is no such thing as an absolutely secure system, it is only possible to reduce the likelihood of hacking. To prevent injections, you should carefully check the parameters received from the user by any available means. Moreover, it is even worth trying to hack your website to find out what vulnerabilities it has: injecting injections, changing the data type, adding shielding characters to fields, uploading a .php file with malicious code, etc. As you can see, sometimes it is better to do it yourself and prevent hacking before someone else does.