Introduction to SQL Injections

SQL injection attacks, where attackers insert SQL queries via client input, threaten websites using SQL databases like MySQL. These can expose sensitive data, alter databases, and even execute system commands. Notoriously dangerous, SQL injections are a major vulnerability in web applications, potentially compromising customer and proprietary information. They're a top concern in the web security community, as highlighted in OWASP's reports.

What is SQL injection?

SQL injection (SQLi) is a form of injection attack that allows malicious SQL statements to be executed. These instructions control a database server that is a top web application. Attackers can get through application security measures thanks to SQL injection weaknesses. The full content of a SQL database may be retrieved by getting past authentication and authorization of a web page or online application. They may also add, alter, and remove records in the database using SQL injection.

How do SQL injection Attacks Work?

To comprehend SQL injection, you must first understand structured query language (SQL). To access, change, and remove data kept in relational databases, programmers utilize the query language SQL. Since the great majority of websites and online applications rely on SQL databases, a SQL injection attack can have negative effects on enterprises.

An SQL query is a request sent to a database to execute a certain activity or purpose, such as querying data or running SQL code. As an illustration, consider the case when a user submits login credentials using a web form to get access to a website. This kind of online form is typically made to only allow particular kinds of information, such as a name and/or password. When that data is added, it is compared to a database, and if they match, entrance is allowed to the user. Access is denied if not.

Now a possible issue arises since the majority of online forms do not have the means to prevent the entry of additional information. Attackers can take advantage of this flaw and utilize the form's input fields to submit their queries to the database. This may provide them the opportunity to engage in a variety of illicit acts, such as stealing confidential information or changing the data in the database to suit their purposes.

The popularity of databases on servers and websites makes SQL injection vulnerabilities one of the oldest and most common forms of cyberattack. The danger of this kind of attack has grown due to several hacker-related advances, most notably the development of tools to identify and exploit SQL injection. These tools, which are freely offered by open-source developers, provide cybercriminals the ability to automatically carry out assaults in only a few minutes by enabling them to access any table or any column in the database with a single click and carry out the attack process.

Types of SQL Injection Attacks

There are several ways that SQL injection may be exploited to create major issues. An attacker might read, change, and remove data in a database by using SQL injection to get around authentication. In extreme circumstances, SQL injection can even be used to issue commands to the operating system, allowing an attacker to escalate their assault inside a network protected by a firewall to one that is more harmful.

SQL injection may be classified into three types: in-band SQLi, inferential SQLi, and out-of-band SQLi.

In-band SQLi (Classic SQLi)

The most prevalent and convenient SQL injection attack is in-band SQL injection. In-band SQL injection happens when the attacker uses the same communication channel to launch and collect the data of their attacks. This technique comes in two sub-variations:

Error-based SQLi:

Error-based SQL injection occurs when the attacker makes use of database errors to communicate with the system. These error messages may contain information that the attacker might utilize to learn more about the database's structure.

Union-based SQLi:

This method takes advantage of the UNION SQL operator, which combines several select statements generated by the database into a single HTTP response. The response can include information that the attacker can use.

Inferential (Blind) SQLi

To get further insight into the server's architecture, the attacker delivers data payloads to the server and watches how it responds and behaves. The name blind SQLi refers to the fact that the attacker cannot see information about the in-band attack since no data is passed from the website database to the attacker.

Blind SQL injections are longer to run but might be just as destructive because they depend on the server's behavior and reaction. Following are some categories for blind SQL injections:

Boolean-based (content-based) Blind SQLi

The attacker requests a result from the application by sending a SQL query to the database. Whether the inquiry is true or false will affect the outcome. Depending on the outcome, the information in the HTTP response may change or not. The attacker can then determine if the communication produced an accurate or inaccurate result.

Time-based Blind SQLi

The attacker sends a SQL query to the database, making it wait (for a time interval measured in seconds) before responding. Depending on how long it takes the database to answer, an attacker can determine if a query is true or false. Depending on the outcome, an HTTP response will either be generated immediately or after a short delay. This allows the attacker to determine if the message they used returned true or false without relying on database information.

Out-of-band SQLi

This type of attack is only possible when specific functionalities on the database server used by the web application are turned on by the attacker. The main purpose of this attack type is to replace in-band and inferential SQLi approaches.

Out-of-band SQLi is carried out when the attacker cannot launch the attack and gather information using the same channel, or when a server is too sluggish or unstable to allow for these tasks to be carried out. These methods rely on the server's ability to issue DNS or HTTP queries to transfer information to an intruder.

Techniques for Bypassing SQL Injection Protections

Several strategies take advantage of certain SQL features to get around the protections.

White Space

White space is the first strategy we may employ to try to avoid signature detection. Additional spaces and other special characters, such as tabs and new lines, won't change the SQL statement but may allow malicious payloads to bypass filters. As an illustration:

This sentence will operate in the same way as:

Null Bytes

Frequently, the filter will prevent specific characters from being used in a SQL statement. Since the injection is rare to be successful in the absence of special characters like apostrophes or dashes, this is likely the most frequent method of attack thwarting.

By placing null bytes (%00) in front of any banned characters, you can get past this restriction. For instance, the following injection may be used to deceive the filter into permitting apostrophes if we are aware that the program is preventing them:

URL Encoding

Utilizing URL encoding is one additional means of avoiding discovery. Information about web addresses is transmitted over the internet using HTTP and this kind of encoding. All characters other than ASCII values must be converted to valid ASCII characters since URLs can only include ASCII values. Additionally, spaces cannot be used in URLs; instead, they are often transformed into the + sign or%20. It is possible to get around filters by utilizing URL encoding to disguise a malicious SQL query. For illustration, consider the following injection:

With URL encoding, it would seem as follows:

Comments

When carrying out SQL injection attacks, taking advantage of how SQL treats inline comments can also help you get past security measures and stay undetected. We can use comments to split up the query and perhaps get around any filters as they may appear in any number of statements and still be legal. For instance, the following comment can be placed between two keywords:

Combinations

Even these patented evasion methods occasionally won't work by themselves, but we may combine them to increase our chances of getting past defenses and finishing an assault. Let's imagine, for illustration, that the application we are targeting has a filter that disallows comment characters. This may be avoided by constructing a query that encrypts these characters to deceive the filter into permitting them. The initial test query is:

The same query with comment characters hidden by URL encoding:

This considerably boosts our chances of success while attempting SQL injection because any of these techniques may be coupled to assist get through annoying filters.

Hex Encoding

Hex encoding substitutes the original SQL statement's characters with their corresponding hexadecimal values. The values 0-15 are represented by sixteen symbols in the base-16 hexadecimal numeral system. A-F stands for numbers 10-15, whereas the numerals 0-9 indicate just that.

Hex encoding can frequently help you avoid detection when used in SQL statements. For instance:

The equivalent in hexadecimal would be:

Character Encoding

Similar to hex encoding, character encoding involves replacing the original SQL statement's characters with the transformed values. The CHAR() function is used in this form of encoding to convert characters into decimal numbers.

Think about the following instance:

In character encoding, the sentence would appear as follows:

Second Order Injections

The last option that we may use to help with signature evasion is a little more difficult, but depending on how the database is set up, this kind of attack may be able to assist after all other methods have failed.

This happens when a web application or database correctly filters user input but stops there after the first query has been processed and confirmed. Our SQL query is dynamically performed and the malicious code is launched when the program carries out some other operation using the database. As a result, this kind of injection may be seen as having two separate phases: the first query that contains the malicious script and a subsequent procedure that executes the malware.

A popular mitigating strategy is to double any single quote in user input before running the query against the database. Let's say we have a program that allows users to register for accounts and has a password-reset feature. An example of a SQL query used to establish an account might be as follows:

Since it remains a valid statement even after the single quotes are doubled, the database is not affected by this. Now imagine that we want to modify our password. The following query would be submitted to the database:

Because the username recorded in the database has the value "vivek," the original input is no longer being screened, which creates a SQL injection vulnerability. All we would need to do to take advantage of this is register a username with malicious code, like:

The process of creating the account itself will go well, but when we attempt to update the password, the malicious query will run, avoiding input validation.

How to Prevent SQL Injections?

SQL injection issues are difficult to avoid. Specific preventive strategies vary depending on the subtype of SQLi vulnerability, the SQL database engine, and the programming language. The following recommendations can assist in preventing a SQL injection attack:

Avoid using dynamic SQL.

• SQL statements should not contain user-provided input directly.
• Choose the safest options, such as parameterized queries and prepared statements.
• In general, stored procedures are safer than dynamic SQL.

Sanitise user inputs

• Escape the characters that need to be escaped correctly.
• Examine to see if the data type provided corresponds to the intended data type.

Avoid storing confidential information unencrypted.

• Data that will be saved in the database should be encrypted.
• The encrypted hashes should be salted.
• Additionally, this adds a layer of security if sensitive data is successfully exfiltrated by an attacker.

Limit database rights and permissions.

• Reduce the database user's capabilities to the absolute minimum.
• This will restrict what an intruder can accomplish if they can get inside.

Keep users from seeing direct database faults.

• These error messages might be used by attackers to learn more about the database.

Use a Web Application Firewall (WAF) for web services that access databases.

• This shields web-based apps against harm.
• It can assist in detecting attempts at SQL injection.
• Depending on the configuration, it may also aid in preventing attempts at SQL injection from getting through to the program and, consequently, the database.
• Depending on the configuration, it may also aid in preventing attempts at SQL injection from getting through to the program and, consequently, the database.

Use a web application security testing solution to test web programs that interface with databases regularly.

• By doing this, you may help prevent regressions or new problems that could lead to SQL injection.
• By doing this, you may help prevent regressions or new problems that could lead to SQL injection.

Maintain database updates using the most recent changes.

• This stops attackers from taking use of known flaws or defects in earlier versions.