SQL Injection Attack Definition
Structured Query Language (SQL) has been the standard for handling relational database management systems (DBMS) for years. Since it has become common for internet web applications and SQL databases to be connected, SQL injection attacks of data-driven web apps, also simply called SQLi attacks, have been a serious problem.
A SQLi attack happens when an attacker exploits a vulnerability in the web app’s SQL implementation by submitting a malicious SQL statement via a fillable field. In other words, the attacker will add code to a field to dump or alter data or access the backend.
A successful malicious SQL statement could give an attacker administrator access to a database, allowing them to select data such as employee ID/password combinations or customer records, and delete, modify, or data dump anything in the database they choose. The right SQL injection attack can actually allow access to a hosting machine’s operating system and other network resources, depending on the nature of the SQL database.
What is SQL Injection Attack?
SQL injection is a common attack vector that allows users with malicious SQL code to access hidden information by manipulating the backend of databases. This data may include sensitive business information, private customer details, or user lists. A successful SQL injection can result in deletion of entire databases, unauthorized use of sensitive data, and unintended granting of administrative rights to a database.
How Does SQL Injection Work?
The types of SQL injection attacks vary depending on the kind of database engine. The SQLi attack works on dynamic SQL statements, which are generated at run time using a URI query string or web form.
For example, a simple web application with a login form will accept a user email address and password. It will then submit that data to a PHP file. There is a “remember me” checkbox in most forms like this, indicating that the data from the login session will be stored in a cookie.
Depending on how the statement for checking user ID is written in the backend, it may or may not be sanitized. This example statement is not sanitized, and is vulnerable:
SELECT * FROM users WHERE email = $_POST['email'] AND password = md5($_POST['password']);
This is because although the password is encrypted, the code directly uses the values of the $_POST[] array.
If the administrator should use “admin@company.com” and “password”, like this:
SELECT * FROM users WHERE email = 'admin@company.com' AND password = md5('password');
An SQLi attacker simply needs to comment out the password portion and add a condition that will always be true, such as “1 = 1”.
This creates a dynamic statement that ends with a condition that will always be true, defeating the security measures in place:
SELECT * FROM users WHERE email = 'xxx@xxx.xxx' OR 1 = 1 LIMIT 1 -- ' ] AND password = md5('password').
Popular SQL Injection Attacks
There are several types of common SQL injection attacks. Typically, popular SQL injection attacks include classic SQLi, also called in-band SQLi; blind SQLi, also called inference SQLi; and out-of-band OOB SQLi, also called DMS-specific SQLi.
Classic or basic SQL injection attacks are the simplest and most frequently used form of SQLi. These classic or simple SQL injection attacks may occur when users are permitted to submit a SQL statement to a SQL database. There are two main varieties: UNION-based attacks and error-based SQLi.
UNION-based attacks extract precise data by determining the structure of the database using the SQL UNION operator. Error-based SQLi reveals either specific information or structural details about the database by creating a related SQL error with a web app.
Blind SQLi attacks are similar to classic attacks in that they may be error-based, UNION-based, or another familiar variety. However, the major difference with blind or inference SQL injection attacks is that the attacker doesn’t get specific text or an error message that demonstrates their attack’s success or failure.
The blind attack still does cause a web app to behave differently, and the attacker can then infer the structure of the database from how it responds to the SQL query. They can then use those inferences to build a copy of the database one character at a time—although this highlights the impractical nature of a blind SQL injection attack for many situations involving very large databases.
There are two types of blind SQL injections: boolean and time-based.
In a boolean based blind SQL injection attack, the attacker queries the database and the application returns a result. Whether the query is true or false determines the result, and whether the information in the HTTP response will remain unchanged or be modified. This in turn allows the attacker to determine whether the message generated a true or false result.
Time-based SQL attackers send SQL queries to the database, which must then wait to react. How long the response time is shows the attacker whether a query is true or false.
Although it is a less common type of attack, an out-of-band SQLi is still a risk. This kind of attack involves submitting a DNS or HTTP query that contains a SQL statement to the database. The success of this kind of attack depends on certain features of a SQL database being enabled.
Finally, a compound SQLi attack refers to using standard SQL injection attack techniques in tandem with other cyberattacks. For example, using SQLi with denial of service, cross-site scripting, insufficient authentication, or DNS hijacking attacks allows hackers new ways to get around security measures and avoid detection.
Who is At Risk for SQL Injection Attack?
Knowing how to prevent SQL injection attacks starts with understanding organizational risk. There is really one basic criterion for SQL injection attack risk: having a website that is connected to and interacts with a SQL database. However, data-driven web applications are at special risk for this kind of attack due to the high amounts of data they collect and store.
A data-driven web app is any application that modifies its behavior based on user data. Examples of this sort of data-driven app include:
- guest books;
- notification/reminder apps;
- report-generating apps;
- search apps;
- social media platforms;
- survey/quiz apps; and
- workflow apps.
SQL Injection Attack Examples
Some of the biggest SQL injection attacks can cause extensive results, including:
- copying or deletion of portions of, or the entire, database, including sensitive data such as health records or credit card information;
- modification of the database, including adding, changing, or deleting records;
- impersonated users, spoofed login credentials, or an entirely bypassed authentication process;
- execution of OS commands that allow access to other network assets; and
- an advanced SQL injection attack may take the target DBMS or web app offline completely.
There are several recent SQL injection attack examples that illustrate this kind of risk. In 2018, a vulnerability that bestowed elevated shell privileges to attackers on certain systems that were vulnerable—now patched—was found in Cisco’s Prime License Manager. In 2019, malicious SQL commands targeted the Fortnite website, allowing unauthorized access to user accounts.
How to Prevent SQL Injection Attacks
The Open Web Application Security Project OWASP provides an overview of how to avoid SQL injection attacks. While there are various SQL injection attack tools on the market, there is no substitute for implementing best practices for preventing these attacks. Here are some of the OWASP top strategies for preventing SQLi attacks.
Prepared statements/parameterization
All database queries should be written as prepared statements with parameterized queries. This means that all SQL code for the query will be defined in advance, so the database can distinguish between user inputs and code—and will treat any malicious SQL query as data, not malicious code.
Stored procedures
Stored procedures are similar to prepared statements in that both define valid SQL statements in advance. However, stored procedures remain in the database, while the SQL code of prepared states is stored in the web app. Stored procedures are not as secure as prepared statements, and can be unsafe when dynamic SQL generation takes place inside them.
Input validation
Input validation or sanitation attempts to control the kind of user input the system receives. When there is no way to prepare everything in advance and some SQL code is a core component of user input, it is critical to allow only valid SQL statements.
Only the most essential statements should be included on such a list to avoid unvalidated statements in a query. Validate not only fields where users type in data, but also fields with buttons or drop-down menus. Refer to the OWASP input validation cheat sheet here.
Web application firewall (WAF)
A web application firewall (WAF) is an important part of a larger security solution that detects SQLi along with other threats. WAFs typically do this in part by relying on detailed lists of signatures that are constantly updated, so they can surgically excise threats, including malicious SQL queries.
Escape user-supplied input
This is a tactic that tries to target certain characters in SQL statements to prevent attacks. Specifically, a particular escape function will add a neutralizing character such as a “” to a command to prevent malicious versions from correctly being executed. This is not a very reliable method on its own.
Limit privileges
OWASP recommends limiting application account privileges for your database in particular. For example, if a site only needs SELECT statements from a database to function, its database connection credentials should never have additional privileges such as DELETE, INSERT, or UPDATE privileges.
Granting admin access in these cases may enable more smooth running, but it also leaves the database vulnerable. Various user accounts for web apps can also have access to only specific fields, so that any one attacker has only a limited view of the data.
Update and patch regularly
Always update and make sure you have the latest security patches from every vendor for all web application software components, including database server software libraries, frameworks, plug-ins, and web server software.
Smarter configuration
Configure error reporting and handling properly in the code and on the web server. You want to avoid sending wordy database error messages containing technical details to the client web browser that can provide leverage for attack.
Does VMware NSX Advanced Load Balancer offer an SQL Injection Attack Defense?
The VMware NSX Advanced Load Balancer WAF protects web applications from OWASP Top 10 threats such as SQL Injection Attacks and Cross-site Scripting (XSS) and other common security vulnerabilities while offering customizable rule sets for each application.
The architectural advantages of the VMware NSX Advanced Load Balancer platform power the platform’s WAF, gaining real-time application security insights thanks to the platform’s strategic location in the application traffic path. This architectural advantage and the platform’s multi-cloud capabilities extend to WAF network security. Learn more about how the platform’s WAF helps to prevent SQL injection attacks.
For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.