Which type of SQL injection attack occurs by adding a condition that is always true to a query?

Introduction to SQL Injection

SQL Injection is a code injection technique used to attack data-driven applications by inserting malicious SQL statements into the execution field. The database is a vital part of any organization. This is handled by high-level security in an organization. SQL is a structured query language. Used to interact and to manipulate the database.

What SQL does Exactly?

• Create a new database
• Insert, update, delete records
• Create new queries
• Stored procedures
• Create views
• Execute queries
• Set permissions

It is one of the top security threats. This comes under cybercrime.

In SQL, we have a concept called SQL Injection. This technique is used to inject the code. SQLi (It is also known as a type of hacking, i.e., injection attack.) It is also known as the web hacking technique. This injection injects malicious code into the database by giving input to a web page. These inputs have some conditions, which are always true. With these conditions, hackers easily pass security tests. They can easily get data from the SQL database. With SQL Injection, they can add, modify, and delete records in the database. That database may be anyone among MySQL, SQL Server, Oracle, SQL Server, etc., is illegal. If a website or an application is poorly designed, then these attacks may harm the entire system. So at this point, cybersecurity comes into the picture.

Behavior of SQL Injection

• These attacks generally work on dynamic SQL statements.
• It is database engine-dependent. This differs from engine to engine.
• When we ask for input to the user on the webpage like username and password.
• Unintentionally we are giving the user access to give that input directly into the database.

Types of SQL Injection

Different types are mentioned below:

• In-band SQL injection (Classic SQL injection): In this technique, the hacker uses the same way to hack the database and get the data, i.e., result from the database.
• Error-based SQL injection: In this type, the hacker gets the error pattern of the database and access it. We can say this is the one type of in-band SQL injection.
• Union-based SQL injection: This technique is also a part of in-band SQL injection. The user combines the query and gets the result back as part of the HTTP response in this technique.
• Inferential SQL injection (Blind SQL injection): As the name suggests, here hacker does not use the band to get data from the database. Hacker has the capability to change the structure of the database by observing patterns of the database. This is a very dangerous type. This attack takes a long time to execute. Hacker is not able to see the output of the attack by this technique.
• Boolean-based (content-based) Blind SQL injection: This is a part of Inferential SQL injection. In this technique hacker forces the database to fetch results based on true or false conditions. Depending upon this condition result of the HTTP response gets changed. This kind of attack can infer if the payload used returned true or false, even though no data from the database is returned. These are especially slow attacks.
• Time-based Blind SQL injection: This technique is also part of Inferential SQL injection. Hackers use this technique to put the payloads in this technique, hackers giving time to the database to execute the query. Meantime hacker gets an idea about the result, whether it is true or false. This process of attack is also slow in nature.
• Out-of-band SQL injection: This is a feature-based attack. This is not very common. A hacker uses this attack when a hacker needs to use different channels to attack and others to get the result. Out-of-band SQL injection techniques are dependent on the database server’s ability to make DNS or HTTP requests to deliver data to the hacker.

How does it Work?

There are mainly two ways where the attacker focuses on getting data:

• Direct Attack: Directly using the combination of different values. Here hacker put the confirmed input, which gives the exact result.
• Research: Analyzing the database by giving different inputs. Here, the attacker observes the database server responses and decides which attack has to be done.

As we already seen, SQL injection hackers put the condition in the input element, which is always true.

Example:

Suppose we have the below query to get employee data from the database:

Code:

Suppose we do not have any restriction on the user’s input. Then hackers may use this field to access data from the database easily.

Code:

This query will return data from the database because 1=1 will always return true. In this way condition becomes true. This seems vulnerable. This is very dangerous to the organization. For instance, think about the banking sector. Where users have their net banking details, passwords, balance information, etc.

This technique is very easy for the hacker to get information by simply giving some input to the database.

Hackers get data by simply inserting OR and = by inserting it into the database.

User Name:

” or “”=”

Password:

” or “”=”

At the server, the end query gets executed correctly; no error occurs. Also, you may use ‘ OR ‘1’=’1 to get data from the database server.

Now, the question arises, how would we maintain our database security?

And the answer is by using SQL parameters.

By adding extra parameters at the query when it executes.

These attacks are easily preventable by some below techniques.

• Stored procedures
• Prepared statements
• Regular expressions
• Database connection user access rights
• Error messages, etc are the prevention techniques

One more thing that we should think, it is also sensible to have different databases for different purposes in the application. One more thing that comes across is testing. Testing the database for a different condition is also the best way.

Conclusion

Creating a database is a crucial part. Having the risk of getting information in hackers’ hands is not good for any application. So, while creating the database, we must follow some easy steps to prevent this loss; a phrase suitable for this is ”Prevention is better than cure.”

Recommended Articles

This has been a guide to What is SQL Injection. Here we discuss the behaviour, how does it work, and the respective types. You can also go through our other suggested articles to learn more –

1. What is SQL Server?
2. What is SQL
3. What is SQL Developer?
4. SQL Commands Update

<< Back to Technical Glossary

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 “” and “password”, like this:

SELECT * FROM users WHERE email = '' 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 = '' 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 Avi offer an SQL Injection Attack Defense?

Avi 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 Avi platform power Avi’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 Avi’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.