Ruslan Rakhmetov, Security Vision
One of the main targets of modern cyber attacks are various web applications. They are accessible to a wide range of users, process information of interest to intruders (for example, personal and payment data), and are also susceptible to various vulnerabilities. One of the most popular attack vectors is injection - a web application is vulnerable to injection attacks when the data entered by users is not checked for security. Today we will talk about SQL injections, one of the oldest but still popular methods of attacking web applications.
Let's use simple examples to show what SQL injection is (it can also be referred to as SQL injection, abbreviated as SQLi). To do this, you need to understand how websites and databases that store information for websites interact with each other, including information about products sold, usernames and passwords of users, bank card data, and other valuable information. In the simplest case, the user enters a query in a specific field on the site, for example, by searching for hats available for order in an online store. The website generates an HTTP GET request, which is displayed in the browser's address bar:
hxxps://supershop[.]com/products?category=hats
A web request from the user in the website interface is converted into a database query. It searches for products in the "hats" category with the automatic addition of the condition that hats must be available ("instock = 1"):
SELECT * FROM products WHERE category = 'hats' AND instock = 1
The query is formed in the SQL language (Structured Query Language), which allows you to manage data in relational databases using DBMS such as MS SQL Server, PostgreSQL, OracleDB, MySQL, MariaDB, SQLite. To manage the data placed in columns and rows in a database table, SQL commands are used (for example, SELECT, INSERT INTO, UPDATE, DELETE), and other SQL commands are used to manage the tables themselves (for example, ALTER TABLE, DROP TABLE).
Security researchers realized that if the logic of a web application or security solutions does not filter out the input of special characters from the user, then you can create an arbitrary query by entering the following in the browser's address bar:
hxxps://supershop[.]com/products?category=hats' OR 1=1--
In this query, we put a special character - a single quotation mark (a separator to indicate a sequence of characters in SQL), the logical expression "OR 1=1" ("OR 1=1", which will always be true) and two hyphens. The first character (single quotation mark) is used to close the original query so that the website does not start searching for the product category corresponding to the text string "hats OR 1=1--". The logical expression "OR 1=1" is used to display the entire list of products on the screen - not only hats, but also everything in the store. Two hyphens ("--") are used in SQL as comment symbols, which means that all further parts of the SQL query ("AND instock = 1") will be ignored in order for the query to return more than just the items in stock.
As a result, the web query is converted into the following SQL expression:
SELECT * FROM products WHERE category = 'hats' OR 1=1--' AND instock = 1
This SQL query is similar to the "SELECT * FROM products" query, which will result in displaying the entire list of products, which attackers can use to view hidden products or create unnecessary load on the site.
More serious consequences will occur if the attackers log in under an administrator account, taking advantage of the same vulnerability of the website to SQL injections. Even if the administrator's username and password are unknown, attackers can try to enter the following expression in the login field (leaving the password blank):
' OR 1=1--
Thus, a web request will be generated in the form:
hxxps://supershop[.]com/users?login=' OR 1=1--
In this case, the DBMS will process an SQL query like:
SELECT id FROM users WHERE login = ' ' OR 1=1--' AND password = ' '
In this case, the login condition contains an empty value surrounded by single quotes and the boolean expression "OR 1=1" (it always returns the correct result, so the condition is met even with an empty login), and the rest of the password verification query is commented out. Thus, attackers will be able to access the site under the account of the first user from the "users" table - most likely it will be the administrator. However, since the generated SQL query returns all the "id" values from the "users" table, this may go against the logic of a web application that can expect only one value. In addition, the "OR 1=1" construction when using UPDATE or DELETE statements can lead to undesirable consequences for an attacker, including deleting data in the table.
The examples given are very simple, and real attacks use not only the GET requests used above, but also POST requests and SQL injections by modifying user-controlled cookies and HTTP headers. In addition, injections are dangerous not only for relational databases, but also for non-relational (NoSQL) databases. To implement the attack, you will need a slightly more complex syntax that takes into account the specifics of the DBMS used (for example, MongoDB, Redis, Apache Cassandra, Oracle NoSQL).
The consequences of an attack using SQL injection can be:
1) Compromise of credentials, impersonation of other users and administrators of the web application and database;
2) Receiving, changing, deleting any data stored in the database;
3) Management of the entire DBMS, with the ability to delete tables and existing databases;
4) Denial of service implementation of a web application or database by running "heavy" queries;
5) Gaining access to the OS on which the DBMS is installed, executing OS commands, managing services, accessing the registry and file system on behalf of the account from which the DBMS is running.
The Open Web Application Security Project (OWASP) published the first version of its list of the 10 most common types of web vulnerabilities and web application configuration errors in 2003, and the injection attack, including SQL injection, was listed at number 6. However, the first assumptions about the possibility of exploiting application injection vulnerabilities, i.e. implementation of unsafe user data appeared back in 1998, when an article was published describing the possibility of introducing unsafe designs in combination with the then-current MS IIS 4.0 web server and the MS SQL Server 6.5 DBMS. Already in 2002, SQL injection was used in a demonstration attack on the fashion retailer Guess - researchers were able to access bank card data of more than 200 thousand website users and reported this to Guess, which fixed the vulnerability, but nevertheless paid a fine in 2003 for violating customer data protection rules.
Subsequently, attackers improved their knowledge of methods for implementing SQL injections, a classification of the types of such attacks appeared, and their popularity only grew. Thus, injection attacks took first place in the OWASP Top-10 list in 2010 and held the top position until 2021, when they moved to 3rd place in the OWASP Top-10 list and were combined with XSS vulnerabilities. The reasons for the appearance of SQL injections are described on the page with the description of CWE-89: Improper Neutralization of Special Elements used in an SQL Command ("Incorrect neutralization of special characters used in an SQL command"), and methods of attacks using SQL injections are described on the page with the description of CAPEC-66: SQL Injection.
Attacks using SQL injection are still actively carried out, despite their popularity for more than 25 years. The CISA KEV (Known Exploited Vulnerabilities) catalog contains data on the use of SQLi vulnerabilities in large-scale cyber attacks, for example:
· CVE-2025-25257 (vulnerability to SQL injection of the Fortinet FortiWeb application layer firewall);
· CVE-2025-25181 (vulnerability to SQL injection of the SaaS logistics platform Advantive VeraCore);
· CVE-2024-9465 (vulnerability to SQL injection of the Palo Alto Networks Expedition data migration tool);
· CVE-2024-29824 (vulnerability to SQL injection of Ivanti Endpoint Manager Endpoint management solution);
· CVE-2023-34362 (vulnerability to SQL injection of the popular corporate web application MOVEit Transfer, which resulted in the hacking of more than 2,700 companies worldwide).
Currently, the following classification of SQL injections has been adopted according to their implementation methods:
1. Classic SQL injections (also called "in-band SQL injection): In them, the vulnerable web application returns the injection result to the attacker through the same communication channel. For example, if an SQLi attack is carried out through a browser, then the result of the attack will be displayed on the web page. The above examples, in which an attacker logs into a website without a password or receives a list of all products, are examples of classic SQL injections.
The following subtypes also belong to classic SQL injections:
1.1. Error-based SQL injection ("Error-based SQL injection") attacks: as a result of a malicious query, the DBMS returns errors to the attacker, which may contain the type and version of the DBMS and information about the database structure. It is from this type of attack that further searches for SQLi vulnerabilities can begin. The classic "educational" way to check a web application for an SQLi vulnerability and view the error message in the DBMS would be to enter a single quotation mark (') in the input form on the site.
1.2. SQLi attacks using the UNION operator ("Union-based SQL injection"): in this attack, the results of the original database query are combined with the results of the query entered by the attacker using the UNION SELECT expression (in this case, the query created by the attacker must return the same number of columns as the original query, and the data types the columns must match).
2. Blind SQL injection ("Blind SQL injection", also called "Inferential SQL injection", i.e., inferential or inference SQL injections): the attacker does not receive an obvious response from the hacked application, but based on its behavior, draws conclusions about the structure of the database and the architecture of the web application.
Blind SQL injections are divided into subtypes:
2.1. Logical blind SQL injections ("Boolean-based blind SQL injection", also called "Content-based blind SQL injection", i.e. blind SQL injections based on content): attackers combine legitimate queries with logical conditions (such as "AND 1=1" or "AND 1=0") and try to figure out the structure or read the contents of the database, focusing on indirect signs and changing responses of the web application to such queries.
2.2. Temporary blind SQL injections ("Time-based blind SQL"): attackers combine legitimate queries with SQL queries that are executed with a delay, and based on the analysis of the changed behavior of the web application, they draw conclusions about the structure or content of the database.
3. Out-of-band SQL injections ("Out-of-band SQL injection"): In such attacks, attackers receive the results of their query in another communication channel. For example, the results of a malicious web query come as HTTP or DNS query contents to the attacker's server or are recorded in a network folder controlled by the hacker.
4. Stack queries ("Stacked Queries", also called "Piggy-backed Queries", i.e. imperceptibly attached queries): the attacker adds a malicious query to the legitimate one using the query separator (;) in the data entry field (however, not all DBMS support stack queries).
5. Second-order SQL injections ("Second Order SQL Injection", also called "Stored SQL injection", i.e. stored SQL injections): the attacker pre-stores malicious constructs in the database of the attacked resource and then calls them in other requests.
6. Attacks using vulnerable stored procedures ("Stored Procedure Attack"): When a stored procedure processes user input data, it may be vulnerable to SQL injections.
7. ORM injections ("Object Relational Mapping Injection"): to ensure secure access of a web application to a DBMS, intermediate links can be used, for example, through the use of ORM (Object-Relational Mapping, object-relational transformation) technology, which mediates between the application and the DBMS. In this technology, despite the purposes of its application, vulnerabilities can also be discovered and injections can be implemented, including those described in CAPEC (CAPEC-109: Object Relational Mapping Injection).
8. Attacks using advanced stored procedures embedded in MS SQL Server: if configured incorrectly, attackers may be able to run OS commands on behalf of the account from which the DBMS is running, as well as manage services, access the registry, file system, and network. Such stored procedures built into MS SQL Server as xp_cmdshell, xp_regdeletekey, xp_servicecontrol, xp_availablemedia, xp_ntsec_enumdomains and others can be used. In addition, you can get an NTLM hash from the password of the account from which MS SQL Server is running, for example, by accessing a network folder using the extended stored procedures "xp_fileexist" and "xp_dirtree" or by using the BULK INSERT statement.
To automate SQLi attacks, attackers use various tools, the most famous of which are sqlmap, sqlninja, and SQLDump. SQL injection protection methods are also known:
1) sanitization (cleaning) of user-entered data, the use of "whitelists" for user-entered data (for example, selecting a value from a list rather than entering it manually), filtering data by expected types (for example, only natural numbers, only alphanumeric characters);
2) using parameterized queries;
3) writing secure stored procedures;
4) implementation of the principle of least privilege - granting the minimum necessary access rights to accounts from which the DBMS is launched, web applications are running on the server, and the web application is accessing the DBMS. It is necessary to restrict access rights to individual tables, if possible, provide read-only access to data, create views and provide access only to them, provide access only to necessary stored procedures, and create separate accounts with granular privileges for each web application that requires access to the database.;
5) using techniques and frameworks with built-in protection mechanisms against SQL injections;
6) Secure DBMS configuration according to recommendations
and best practices;
7) implementation of the Zero Trust concept, including network micro-segmentation, conditional access, and data categorization;
8) the use of Database Security platforms, solutions for controlling the processing of structured data processed in databases with the functionality of configuring and applying data processing policies, controlling and restricting access rights to them, and logging data processing;
9) the use of application-level firewalls (WAF, Web Application Firewall) - software or hardware solutions for network security designed to ensure the security of web applications by blocking suspicious activity (including SQL injection attempts) and installing virtual patches;
10) using tools for static code analysis (SAST, Static Application Security Testing), dynamic application analysis (DAST, Dynamic Application Security Testing), interactive application analysis (IAST, Interactive Application Security Testing), behavioral application analysis (BAST, Behavioral Application Security Testing).
.jpg)
.jpg)
.jpg)
