How Cybercriminals Manage to Slip Malicious Code into Systems

In 2018, 59% of companies experienced malicious codes and botnets. These create system vulnerabilities including the opening backdoors, file corruption, and data theft. They lead to security breaches that entail large amounts of losses not only in monetary terms but also in business reputation.

There’s no doubt that companies and even individual computer users need to prevent malicious code from penetrating their systems. To have better chances of keeping these threats at bay, it helps to get acquainted with the ways they manage to infect systems.

SQL injection

An excellent example of how malicious codes are inserted into systems is Structured Query Language Injection or SQL injection. It is a common attack vector that employs malicious SQL codes to manipulate backend databases and eventually access information that is supposedly concealed or kept out of access.

SQL is a domain-specific programming language intended for managing data contained in a relational database management system or a relational data stream management system (in the case of stream processing.) SQL makes it possible to create customizable data views for individual users and for users to send commands such as updates, data retrieval, and the removal of records.

Cybercriminals have developed ways to use the standardized Structured Query Language in launching cyber attacks. These attacks are undertaken through SQL injection.

Image credit: Pixabay

Types of SQL Injection

One of the most common web hacking techniques, SQL injection is a code injection method that targets data-driven applications. It introduces a malicious code in SQL statements through web page input. To successfully penetrate, an SQL injection attack needs an exploitable security vulnerability in a software. An example of this vulnerability is the incorrect filtering of string literal escape characters placed in SQL statements. SQL injection is often observed as an attack on websites, but it can also be used to target other types of SQL databases.

There are three types of SQL injections, namely the classic (in-band SQLI), inferential (blind), and out-of-band SQLI. This classification is based on the method each of them employ in accessing data and the damage potential they entail.

Classic SQLI makes use of one channel for both the communication of an attack and the retrieval of the results. It’s a simple form of SQL injection, which makes it one of the most common types of SQLI attacks. It can be error-based or union-based. The former means that the perpetrator of the attack initiates actions that yield database errors, which results in the generation of error messages that can provide information on the structure of the database. The latter exploits the UNION SQL operator, which integrates a number of statements generated by the database to obtain an HTTP response. The attacker needs this HTTP response to get data that can be used to pursue security breaches.

Blind or inferential SQLI involves the sending of data payloads to a target server and the observation of the response and subsequent behavior of the server. It is generally a slower attack to execute but just as harmful as other SQLI attacks. It is called a blind attack because the data response of the targeted server does is not transmitted to the attacker. Inferential SQL injections are of two types: time-based and boolean. In time-based attacks, the attacker sends to a database a query that makes the database wait for a few seconds before it reacts. The attacker then observes the time it takes for the database to respond. The response duration can indicate if a query is true or false. Under this scheme, an HTTP response is produced either immediately or after the waiting period, which allows the attacker to deduce if the message used returned a true or false response.

Out-of-band SQL injection, on the other hand, is mainly used as an alternative attack since it can only be carried out when specific server features are activated. This is the go-to attack when it’s not possible to use the same channel to launch an attack and obtain information. It is also the attack of choice in cases when the target serves are notably slow or unstable. Out-of-band SQLI rely on the ability of a server to generate DNS or HTTP requests to transmit data to the attacker.

How SQLI Attacks Work

Here’s a simple example of how SQL injection attacks proceed.

First, the attacker manipulates a standard SQL query to take advantage of non-validated input weaknesses in a database. 

Here’s an example of an SQL query, which is generated after the user-supplied input “”

SELECT ItemName, ItemDescription


WHERE ItemNumber = 999

The attacker can manipulate this SQL query by changing the user-provided input above (the page URL) to “ or 1=1.”

The query is then converted to the following:

SELECT ItemName, ItemDescription


WHERE ItemNumber = 999 OR 1=1

This query means that there is a request for the database to return all product information contained in the database since the statement 1=1 is true all of the time. Even information that is not meant to be made publicly accessible can be retrieved using this exploit. The item number condition has been overridden by the injected statement.

If the attacker’s goal is not to retrieve information from a database but to alter it, a vulnerability concerning incorrectly filtered characters can be exploited. For example, using the same user-provided input above, the SQL query can be modified into the following:

SELECT ItemName, ItemDescription



This query leads to the deletion of the database.

Moreover, if the attacker intends to gather data contained in different database tables, the manipulation can be framed with a UNION SELECT statement. Going back to the same user-provided input, it can be changed into “ UNION SELECT user-name, password FROM USERS” to yield the following SQL query:

SELECT ItemName, ItemDescription


WHERE ItemNumber = ‘999’ UNION SELECT Username, Password FROM Users;

This query makes it possible to obtain usernames and passwords for every user in the database.

How to Stop SQLI Attacks

SQL injection can be prevented primarily through input validation and advanced web application firewalls.

Also known as input sanitization, Input validation refers to the writing of codes designed to detect and stop malicious user inputs. In the examples above, the database can be written to not allow URLs with appended statements like the “or 1=1” in “ or 1=1.”

Unfortunately, input sanitization is far from foolproof. It would take a lot of work to determine all possibly illegitimate or anomalous inputs and block them. Also, doing so can result in numerous false positives, which can mean a graveling user experience. These false positives can also adversely affect the functionality of web applications.

By Anonim Adam (Own work) [CC-BY-SA-3.0 (], via Wikimedia Commons

Advanced web application firewalls (WAFs) have been created to address these drawbacks. These firewalls filter malicious SQL queries through a continuously updated threat database and precisely crafted signatures. WAFs may also take information from other sources to add new functions and enhance their security capabilities.

There are cloud-based WAFs that feature IP reputation scanning, signature recognition, and other security techniques to detect and prevent the execution of commands initiated by SQLI attacks while reducing instances of false positives. You can find one with a custom security rule engine designed to allow granular custom security configuration and the generation of new case-specific principles to augment the identification of malicious codes as new attacks emerge.

The Takeaway

Obtaining information from databases can be as easy as modifying user-supplied inputs, web page URLs in particular, to generate SQL queries that execute commands that are supposedly prohibited or inaccessible. This is the threatening “magic” of SQL injection. The good news is that there are ways to arrest this exploit by setting rules that disallow malicious queries from being transmitted or executed by a database. For those who don’t want to go through the technical code crunching, there are web-based tools or solutions that can simplify the prevention of SQLI, specifically the use of web application firewalls.