SQL Injection - Types, Examples, and Tools

Watch this SQL Injection Tutorial Video:

An SQL injection attack is when an attacker executes invalid or threat SQL statements where it is used to control the database server of a web application. It is used to modify, add or delete the records in the database without the user’s knowledge. This compromises the data integrity. One of the most important steps to avoid SQL injection is input validation.

There is a wide range of SQL injection vulnerabilities, techniques, and attacks that arise from different situations. Some common examples of SQL injection are:

• Retrieving hidden data and modifying an SQL query to return additional results
• Subverting application logic by changing a query interfering with the application’s logic
• UNION attacks that retrieve data from different database tables
• Examining databases and extracting information about their version and structure
• Blind SQL injection that does not return the results of a query that is controllable in the application’s response

SQL injections typically fall under three categories based on the techniques used and their damage potential.

In in-band SQLi, the attacker utilizes the same communication channel to attack and to gather the results. In-band SQLi’s simplicity and efficiency is the reason for its popularity and wide usage. This method has two sub-variations:

• Error-based SQLi: The attack causes the database to produce error messages. The attacker can also use the data from these error messages to collect information about the database structure.
• Union-based SQLi: This variation uses the UNION SQL operator to get a single HTTP response by fusing several select statements generated by the database. The response may contain data that can be leveraged by the attacker.

In this type of SQL injection, the attacker sends data payloads to the server. They then monitor the server’s behavior and response to learn more about its structure. Blind SQLi is named so because no data transfer happens from the website database to the attacker, thus making the attacker blind to the attack.

Since Blind SQL injections rely on the server response and behavior, they can be slow to execute but can prove to be just as harmful. Blind SQL injections can be classified as:

• Boolean: The attacker sends an SQL query to the database, prompting the application to return a result. Depending on the status of the query, the result will vary and, based on that, the information within the HTTP response will change or stay unchanged. The attacker will then figure out the status of the message.
• Time-based: The attacker sends an SQL query to the database that makes it wait for a few seconds before it reacts. From the response time, the attacker can see whether a query is true or false. Based on that, an HTTP response is generated promptly or after a waiting period. In this way, the attacker can figure out if the message returned true or false, without having to depend on the database data.

This form of attack is only possible when certain features are enabled on the database server that is used by the web application. Out-of-band SQLi is primarily used as an alternative to in-band and inferential SQLi methods. It is used when attackers cannot use the same channel to launch the attack and gather information. It is also used in case of an unstable or slow server, which does not allow these actions to be performed. This form of attack relies on the capacity of the server to create HTTP or DNS requests to transfer data to an attacker.

To perform an SQL injection attack, the attacker must first find vulnerable user inputs in the web page or application. If a vulnerability exists, such user input is used directly in an SQL query by the web page or application.

The attacker can create input content called a malicious payload. This input content plays a critical part in the attack. After the attacker sends this input content, malicious SQL commands are executed in the database.

We already know that SQL injection represents a web security vulnerability that allows the viewing of data, which the attacker should not otherwise be able to view. This is possible by interfering with the queries that the application makes to its database. This is done by injecting malicious SQL injection payloads.

The following are a few tools that are used for SQL injection attacks:

• SQLMap: It is used for automatic SQL Injection And it is a Database Takeover Tool
• Blind-Sql-BitShifting: It is a blind SQL Injection using BitShifting
• jSQL Injection: It is a java tool used for automatic SQL Database Injection
• BBQSQL: It is a blind SQL Injection Exploitation Tool
• Whitewidow: Scanning tool for the vulnerability of SQL Database
• explo: It is a human And Machine-Readable Web Vulnerability Testing Format
• Leviathan: It is a wide range of audit toolkit
• Blisqy: It is used to exploit time-based blind-SQL injection in HTTP-Headers

SQL Injection Detection Tools:

Spider testing tool is used to identify the SQL injection holes manually by using GET or POST requests. Resolving the vulnerabilities in the code can prevent SQL injections. A web vulnerability scanner can be used to identify the defects in the code, so as to fix it to prevent SQL injection. Firewalls in the application layer or web application can be used to prevent intrusion.

If you are able to detect vulnerable points in your application software, then you will be able to find ways to protect them as well. Below are the steps that will help you to test whether your base security is strong enough to prevent SQL injections.

1. Random SQL

Start by inserting an SQL statement in any field and checking the response.

SELECT * from userstable
*

Consider the following message:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’ [Microsoft] [ODBC SQL Server Driver][SQL Server]Syntax error Invalid string or buffer length.

The above message will reveal information about your database. It will also identify the platform used to create the web service. Malicious attackers can use this information in subsequent attacks.

2. Wildcards

This step requires entering an SQL wildcard.

    *
    *

The two steps discussed so far are similar and unlikely to result in errors. However, it is best to eliminate the possibility of SQL wildcards being used by potential attackers.

3. Classic SQL

This is the most common SQL injection test.

     ' or 1=1--
    ' or 1=1--

The following SQL statement helps check the login:

SELECT * FROM users WHERE username = '[username]' AND password ='[password]';

If the element’s content is not checked, the statement should be as follows:

SELECT * FROM users WHERE username = or 1=1 - -' AND password ='[password]';

This way, the SQL server excludes everything after the – sign and returns the first user, usually the administrator, in the database. This could allow a potential attacker to log in. Protection is crucial since the first user, in most cases, could be an administrator.

4. Empty Strings

This test is a variation of Classic SQL.

     ' or ''='
    ' or ''='

The following SQL is the result, and it returns all records in the database, providing the possibility of access to the service:

SELECT * FROM users WHERE username ='' or ''='' and Password = '' or ''=''

5. Type Conversions

Make an attempt to expose the database. This is achieved by sending type conversions, which will fail in the database.

    CAST('smartbear' AS SIGNED INTEGER)
    yesitdoes!

By sending an error message, this SQL statement will expose the database. As we are already aware, any information about the database or application platform can expose specific additional vulnerabilities.

The only way to prevent SQL injection attacks for sure is through input validation and parameterized queries including prepared statements. The input should never be used by the application code directly. All inputs must be sanitized by the developer.

Developers must ensure that all potential, malicious code elements, such as single quotes, are eliminated. The visibility of database errors on production sites should be turned off since these can be used with SQL injection to gain database information.

If an SQL injection vulnerability is discovered, it may not be immediately fixable. For example, in cases where there are vulnerabilities in open source code, you can use a web application firewall to sanitize your input temporarily.

The following are some tips to help prevent SQL injections.

Create Awareness

Everyone involved in the web application development process must be aware of the risks associated with SQL injections. Suitable security training should be in place for developers, QA team, team, and sysadmins.

Don’t Trust User Inputs

Any user input that is used in an SQL query introduces a risk of SQL injection. Therefore, treat input from even authenticated or internal users like you would treat any public input.

Use Whitelists and Not Blacklists

While it may seem very obvious to use blacklists to filter user input, it will not get past a clever attacker. They will almost always find a way around the blacklist situation. So, If possible, make sure to verify and filter user input based strictly on whitelists.

Be Up-to-date with Latest Technologies

Always employ the latest version of the development environment and language along with the latest technologies associated with them. For example, in case of PHP use PDO instead of MySQLi.

Only Use Verified Mechanisms

Most development technologies today offer mechanisms to protect against SQLi. So, don’t try to build one yourself from scratch. For example, make use of parameterized queries or stored procedures.

Regularly Scans

SQL injections may be introduced to web pages and applications by your developers or through external libraries, software, or modules. So, it is recommended to regularly scan these web applications using a web vulnerability scanner.

Wireless networks or Wi-Fi is the current generation’s most preferred medium of network connectivity, but it is subjected to a lot of security issues. If the attacker has access to the network connection, then they can easily sniff the network packets from a nearby location. They use sniffing to find the SSID and hack wireless networks. They then monitor the devices connected to the same network SSID. WEP authentication can also be subjected to dictionary attacks. WEP authentication uses an RC4 encryption algorithm to create stream ciphers, which are easy to crack. WPA authentication to is vulnerable to DOS and dictionary attacks.

Tools used for Wireless network hacking:

For WEP cracking tools, the attackers use Aircrack, WEPcrack, Kismet, and WEPDecrypt. For WPA cracking, tools like CowPatty, Cain & Abel are used. There are also other general types of tools used for Wireless network hacking such as Airsnort, Wireshark, Netstumbler, Wifiphisher, and so on.

Mobile platform hacking:

Mobile phones have become the most used device by everyone. Android is the most common platform, but it is susceptible to certain vulnerabilities. The biggest hacking threats to Android are data in transit (wireless hacking), third-party applications, SMS, and email Trojans. In order to protect the android device, we can use SSL encryption for the device, download only trusted android third-party apps, and not be subjected to any suspicious email or SMS threads.

Tools in mobile platform hacking:

There are several tools used for android hacking such as AndroRat, Hackode, zANTI, Droidsheep, DroidBox, NMap, and so on. Similarly, iOS devices can be subjected to hacking using iRET, iWep Pro, iSpy, Hopper App, Frida, and so on.