SQL Injection Attack

What is a SQL injection?

A SQL injection attack consists of an insertion or injection of a SQL query via the input data from the client to the application. SQL commands are injected into data-plane input that affect the execution of predefined SQL commands. A successful SQL injection exploit can read sensitive data from the database, modify database data (viz., insert, update, or delete), execute administrative operations on the database, recover the content of a file present in the database management system, and even issue commands to the operating system in some instances.

If a web application or website uses SQL databases like Oracle, SQL Server, or MySQL, it is vulnerable to an SQL injection attack. Hackers use SQL injection attacks to access sensitive business or personally identifiable information (PII), which ultimately increases sensitive data exposure.

SQL injection attacks are one of the most prevalent among OWASP Top 10 vulnerabilities, and one of the oldest application vulnerabilities. One recent report lists it as the third most common serious vulnerabilities.

Why do attackers perform an SQL injection attack?

To perform an SQL injection attack, an attacker must locate a vulnerable input in a web application or webpage. When an application or webpage contains a SQL injection vulnerability, it uses user input in the form of an SQL query directly. The hacker can execute a specifically crafted SQL command as a malicious cyber intrusion. Then, leveraging malicious code, a hacker can acquire a response that provides a clear idea about the database construction and thereby access to all the information in the database.  

SQL serves as the way of communication to the database. SQL statements are used to retrieve and update data in the database. Attackers use malicious SQL statements in the input box, and in response, the database presents sensitive information. This exploit of security aims at gaining access to the unauthorized data of a website or application. Several websites and web applications store data in SQL databases. For any of these applications, it becomes essential to perform vulnerability testing to ensure there are no loopholes for executing SQL injection. 

What are the risks associated with SQL injection attacks?

In an SQL injection attack, an application interprets data submitted by a cyber criminal as a command and responds with sensitive details. An SQL injection can result in a number of risks that may pose severe threats to the organization. Following are some of the scenarios:

• A bad actor hacker performs an SQL injection to delete data or tables from the database. In this case, even if there are database backups, deleting the data can affect the application’s availability until the database can be restored. Further, backups may not include recent data. 
• Attackers use SQL injection to alter or update data in the database and add additional data. For instance, in the case of a financial application, an attacker can use SQL injection to change account balances. Even worse, attackers can gain administrative rights to an application database.
• The most common risk of an SQL injection attack is the theft of user data. Email addresses, login credentials, and personally identifiable information (PII) can be stolen and sold on the dark web. Therefore, a successful SQL injection poses a threat not only to the organization but also its users. 

Even after 20 years of SQL injection discovery, it remains one of the primary concerns when it comes to a data breach and security of data. In fact, recent attack trending analysis shows SQL injection attacks up 47%.

How does a SQL Injection attack work?

SQL injection is performed by using a structured query that instigates the desired response. The response is essential for the attacker to understand the database architecture and to access the secured information of the application. An attacker may perform SQL injection with the following approaches: 

SQL statement that is always true

A hacker executes an SQL injection with an SQL statement that is always true. For instance, 1=1; instead of just entering the “wrong” input, the hacker uses a statement that will always be true. 

Entering “100 OR 1=1” in the query input box will return a response with the details of a table.

"OR ""="

This SQL injection approach is similar to the above. A bad actor needs to enter "OR ""=" into the query input box. These two signs serve as the malicious code to break into the application. Consider the following example. An attacker seeks to retrieve user data from an application and can simply type “OR=” in the user ID or password. As this SQL statement is valid and true, it will return the data of the user table in the database. 

Batched SQL injection

Batched SQL injection comprises a set of SQL statements separated by semicolons. The only thing that can make this approach successful is if the SQL statements are true and valid—that is, the statement after the semicolon needs to be true. For example, if the hacker enters “105; DROP TABLE Supplier,” the SQL statement after the semicolon will delete the supplier table from the application database.

Some of the most common SQL injection queries are included in the next section.

Types of SQL injection attacks

SQL injection can be categorized into three categories: in-band, inferential, and out-of-band.  

In-band SQL injection attack

In-band SQL injection is the most frequent and commonly used SQL injection attack. The transfer of data used in in-band attacks can either be done through error messages on the web or by using the UNION operator in SQL statements. There are two types of in-band SQL injection: union-based and error-based SQL injection.

• Union-based SQL injection. When an application is vulnerable to SQL injection and the application’s responses return the results for a query, attackers use the UNION keyword to retrieve data from other tables of the application database.
• Error-based SQL injection. The error-based SQL injection technique relies on error messages thrown by the application database servers. Here, attackers use the error message information to determine the entities of the database.

Inferential SQL injection attack

Inferential SQL injection is also known as a blind SQL injection attack. In a blind SQL injection attack, after sending a data payload, the attacker observes the behavior and responses to determine the data structure of the database.

There are two types of blind or inferential SQL injection attacks: Boolean and time based.

• Boolean based. The Boolean-based technique sends SQL queries to the database to force the application to return a Boolean result—that is, either a TRUE or FALSE result. Attackers perform various queries blindly to determine the vulnerability.
• Time based. The time-based SQL injection attack is often used when an application returns generic error messages. This technique forces the database to wait for a specific time. The response time helps the attacker to identify the query returns as TRUE or FALSE. 

Out-of-band SQL injection attack

The out-of-band SQL injection attack requests that the application transmit data via any protocol—HTTP, DNS, or SMB. To perform this type of attack, the following functions can be used on Microsoft SQL and MySQL databases, respectively:

• MS SQL: master..xp _dirtree
• MySQL: LOAD_FILE()

SQL injection cheat sheet    

Organizations need to compile a SQL injection cheat sheet to ensure they effectively prevent SQL injection attacks. Effective vulnerability detection and remediation during application development is a critical linchpin in preventing SQL injection attacks. This requires a comprehensive application security approach that shifts security testing to the left—which incurs significantly less time and cost to remediate—and embeds security within software using instrumentation. The latter creates continuous, real-time security testing versus legacy application security scanning approaches that are point in time and produce large volumes of false positives.

Securing applications in development is only one part of the SQL injection equation. Once code is released into production, the same continuous, accurate application security approach is required. Historically, organizations have relied on perimeter-defense solutions such as web application firewalls (WAFs). However, these use an outside-in approach and rely on signature engines. The result is a high degree of inaccuracy—false positives that consume valuable time triage and diagnosis and missed attacks (false negatives) that incur significant risk. 

Instead, either as a replacement to or as a supplement to WAFs, organizations are turning to runtime application self-protection (RASP) solutions that embed security within software using instrumentation. RASP solutions are highly accurate—thereby virtually eliminating false positives—and detect attacks on vulnerabilities and block them before they can enact a successful exploit. 

In addition to the above, there are a few other security practices that organizations can enact as part of their SQL injection cheat sheet:

• Parameterized queries. A parameterized query is a query in which parameters are used as placeholders and are supplied at execution time. In this type of query, the data types of the parameters are predefined, and in some cases, default values are also set. Doing so causes SQL injection queries to fail. 
• Stored procedures. Stored procedures are the SQL statements defined and stored in the database, which are called from the application. Developers normally build SQL statements with parameters that are automatically parameterized. However, developers can generate dynamic SQL queries inside stored procedures that eliminate the risk.
• Refrain from administrative privileges. Blocking connections with applications to their databases using an account having root access or administrative privilege is also an effective protection. This prevents bad actors  from gaining access to the whole database. Regardless, a non-administrative account server can also be risky for an application, primarily if it is used in various databases and applications.

SQL injection attacks can pose serious risks, and organizations need to ensure they have the right application security solutions in place. It starts when application development commences and extends all of the way through production.