SQL Injection — A Detailed Overview

The OWASP (Open Web Application Security Project) Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. According to OWASP Top 10 (2017), the first on the list is Injection. The Injection may include NoSQL or SQL Injection, LDAP Injection, OS Command Injection, Expression Language Injection etc.

The Concept is identical among all interpreters. Source Code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough result of all parameters, headers, URL, Cookies, JSON, SOAP and XML data inputs.

In this blog we will mainly focus on the one of the most dangerous or vulnerable attack on web applications which is SQL Injection.

SQL Injection is a type of web application injection attack that makes it possible to execute malicious SQL queries that an application makes to its database. A successful SQL injection exploit can allow an attacker to successfully read/modify/delete the sensitive data available in the database. Even the authentication records can also be retrieved too from the database.

How a SQL Injection is performed?

To make an SQL Injection attack, an attacker must first find vulnerable user inputs within the web page or web application. A web page or web application that has an SQL Injection vulnerability uses such user input directly in an SQL query. The attacker can create input content. Such content is often called a malicious payload and is the key part of the attack. After the attacker sends this content, malicious SQL commands are executed in the database.

Types of SQL Injections -

In-band SQLi (Classic SQLi) -

In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-band SQL Injection occurs when an attacker is able to use the same communication channel to both launch the attack and gather results. The two most common types of in-band SQL Injection are Error-based SQLi and Union-based SQLi.

Error-based SQLi -

Error-based SQLi is an in-band SQL Injection technique that relies on error messages thrown by the database server to obtain information about the structure of the database. In some cases, error-based SQL injection alone is enough for an attacker to enumerate an entire database.

Union-based SQLi -

Union-based SQLi is an in-band SQL injection technique that takes advantage of the UNION SQL operator, which fuses multiple select statements generated by the database to get a single HTTP response.UNION attacks, where you can retrieve data from different database tables.

Inferential SQLi (Blind SQLi) -

Inferential SQLi or also known as Blind SQLi may take longer for an attacker to exploit, however, it is just as dangerous as any other form of SQL Injection. In this The attacker sends data payloads to the server and observes the response and behavior of the server to learn more about its structure. This method is called blind SQLi because the data is not transferred from the website database to the attacker, thus the attacker cannot see information about the attack in-band. The two types of inferential SQL Injection are Blind-boolean-based SQLi and Blind-time-based SQLi.

Blind-boolean-based SQLi -

Blind-Boolean based SQL Injection is an inferential SQL Injection technique that allows an attacker sends a SQL query to the database prompting the application to return a result. The result will vary depending on whether the query is true or false. Based on the result, the information within the HTTP response will modify or stay unchanged. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned. This attack is typically slow (especially on large databases) since an attacker would need to enumerate a database, character by character.

Time-based Blind SQLi -

Time-based SQL Injection is an inferential SQL Injection technique that allows an attacker sends a SQL query to the database, which makes the database wait (for a period in seconds) before it can react. The attacker can see from the time the database takes to respond, whether a query is true or false. Based on the result, an HTTP response will be generated instantly or after a waiting period. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned. This attack is typically slow (especially on large databases) since an attacker would need to enumerate a database character by character.

Out-of-band SQLi -

Out-of-band SQL Injection is not very common, mostly because it depends on features being enabled on the database server being used by the web application. The attacker can only carry out this form of attack when certain features are enabled on the database server used by the web application. This form of attack is primarily used as an alternative to the in-band and inferential SQLi techniques. Out-of-band SQL Injection occurs when an attacker is unable to use the same channel to launch the attack and gather results or when a server is too slow or unstable.These techniques count on the capacity of the server to create DNS or HTTP requests to transfer data to an attacker.

Many instances of SQL injection are blind vulnerabilities. This means that the application does not return the results of the SQL query or the details of any database errors within its responses. Blind vulnerabilities can still be exploited to access unauthorized data, but the techniques involved are generally more complicated and difficult to perform.

Depending on the nature of the vulnerability and the database involved, the following techniques can be used to exploit blind SQL injection vulnerabilities:

1. You can change the logic of the query to trigger a detectable difference in the application’s response depending on the truth of a single condition. This might involve injecting a new condition into some Boolean logic, or conditionally triggering an error such as a divide-by-zero.
2. You can conditionally trigger a time delay in the processing of the query, allowing you to infer the truth of the condition based on the time that the application takes to respond.
3. You can trigger an out-of-band network interaction, using out-of-band application security testing (OAST) techniques. This technique is extremely powerful and works in situations where the other techniques do not. Often, you can directly exfiltrate data via the out-of-band channel, for example by placing the data into a DNS lookup for a domain that you control.

Threats by SQL Injection -

1. SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
2. SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
3. The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

How to detect SQL injection vulnerabilities ?

The majority of SQL injection vulnerabilities can be found quickly and reliably using Burp Suite’s web vulnerability scanner or by a tool known as SQL Map.

SQL injection can be detected manually by using a systematic set of tests against every entry point in the application. This typically involves:

1. Submitting the single quote character ‘ or double quote character “ and looking for errors or other anomalies.
2. Submitting some SQL-specific syntax that evaluates to the base (original) value of the entry point, and to a different value, and looking for systematic differences in the resulting application responses.
3. Submitting Boolean conditions such as OR 1=1 and OR 1=2, and looking for differences in the application’s responses.
4. Submitting payloads designed to trigger time delays when executed within an SQL query, and looking for differences in the time taken to respond.
5. Submitting OAST payloads designed to trigger an out-of-band network interaction when executed within an SQL query, and monitoring for any resulting interactions.

How to prevent SQL injection ?

Some of the ways to prevent SQL Injections are -

1. Input Validation or Input Sanitization
2. Parametrize queries
3. Avoiding Assumptions
4. Isolation of Web Servers
5. Regular Patch Update
6. Do not disclose information through errors
7. Enforce type and length checks

Some of the general tips for prevention of SQLi are -

1. Train and maintain awareness -

To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with SQL Injections. You should provide suitable security training to all your developers, QA staff, Dev Ops, and Sysadmins.

2. Don’t trust any user input -

Treat all user input as untrusted. Any user input that is used in an SQL query introduces a risk of an SQL Injection. Treat input from authenticated and/or internal users the same way that you treat public input.

3. Use whitelists, not blacklists -

Don’t filter user input based on blacklists. A clever attacker will almost always find a way to circumvent your blacklist. If possible, verify and filter user input using strict whitelists only.

4. Adopt the latest technologies -

Older web development technologies don’t have SQLi protection. Use the latest version of the development environment and language and the latest technologies associated with that environment/language.

5. Employ verified mechanisms -

Don’t try to build SQLi protection from scratch. Most modern development technologies can offer you mechanisms to protect against SQLi. Use such mechanisms instead of trying to reinvent the wheel. For example, use parameterized queries or stored procedures.

6. Scan regularly -

SQL Injections may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner.

Automating SQL Injection using SQL Map -

SQL map is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

SQL Map comes inbuilt in Kali Linux and if you are operating on other operating system you can get it from its git hub link — https://github.com/sqlmapproject/sqlmap

Use sqlmap — help to get all the options available in the tool.

If any application or website is SQLi vulnerable then the data can be retrieved using following commands -

• To get database — sqlmap -u “http://192.168.1.250/?p=1&forumaction=search" — dbs
• To get tables from the specific database — sqlmap -u “http://192.168.1.250/?p=1&forumaction=search" -D database name — tables
• To get columns from the table — sqlmap -u “http://192.168.1.250/?p=1&forumaction=search" -D database name -T table name — columns
• To get data from the columns— sqlmap -u “http://192.168.1.250/?p=1&forumaction=search" -D database name -T table name -C column name — dump

For further more details on SQL Injection, can refer to the following sites -

What is SQL Injection (SQLi) and How to Prevent Attacks

What is SQL Injection? Tutorial & Examples | Web Security Academy

For any queries contact on my twitter and linkedin profiles -

Lovelesh Gangil - Indore, Madhya Pradesh, India | Professional Profile | LinkedIn

https://twitter.com/loveleshgangil/