SQL injection (SQLi)

Summary

This Document explains SQL injection, how it can be performed on a vulnerable application, different types of SQL attacks, and the prevention methods.

SQL injection

SQL injection vulnerabilities have been identified as one of the most serious risks to Web applications. This type of security threat is defined as a web application vulnerability that allows an attacker to inject SQL commands into the program, exposing all data in the database. This might happen if SQL commands and queries are used without validation or encoding in the application code. The application can run undesired instructions, change data, or intercept data using user-created data tricks, and as a result, an attacker can use SQL injection (SQLi) to create, read, update, delete, or remove data from the database.

SQLi Mechanisms

First-order injections:

when the application processes the input, causing the attacker’s injected SQL query to execute. The first-order injection is divided into 3 subcategories:

1. Injection via human input
2. Injection via cookies
3. Injection through server variables

Second-order injections

Second-order injections involve attackers planting malicious inputs into a system or database to cause an SQLi attack when that input is used later. It occurs when user-submitted values are kept in the database and subsequently used by another application functionality without being escaped or filtered.

SQLI Attacks

Tautology

In a Tautology SQL injection attack, the attacker tries to utilize a conditional query statement to evaluate it as always true. Furthermore, the attacker uses the "WHERE" clause to insert and effectively change a condition into a tautology, which is always true When a SQL statement is transmitted to the database as part of a parameter's value without again being sanitized or escaped. An unauthenticated user who does not know the password can transmit a constructed input that looks something like this. A login form in a website accepts the user-provided email address, and password then submits them directly to the backend. The following code will be executed against the database:

SELECT * FROM users WHERE email = $_POST[’email’] AND password = md5($_POST[‘password’]);

The values of the $_POST[] array are used straight in the above code without being sanitized and the MD5 algorithm is used to encrypt the password. When an attacker enters Email = ‘xx.com‘ OR 1 = 1 – the following code can be exploited:

SELECT * FROM users WHERE email = 'xx@yahoo.com' OR 1 = 1 -- AND password = md5('123');

• The string quotation is completed with a single quote at the end of 'xx.com'.
• OR 1 = 1 is a condition that is always true
• -- AND .... is a SQL comment that removes the password portion from the equation.

In-band SQLi

Union-Based SQLi

In this type of query, an unauthorized query is attached with the authorized query by using the UNION clause. An Example of a Union query:

SELECT * FROM Accounts WHERE user=’’ UNION SELECT *FROM Students—‘AND pass=’’AND eid=

• The result of the first query in the example given above is null and the second one returns all the data in the Students table so the union of these two queries is the student table.

Prevention Methods

Despite the fact that SQL has so many different sorts of attacks. Fortunately, prevention is very simple, as the majority of the solution comprises better handling of the user's data. Although certain treatments have drawbacks, they have shown to be helpful in defending. The following are some SQL attack defense strategies.

Prepared statement

Instead of using dynamic queries, which are vulnerable to SQL injection attacks, this solution involves defining all the SQL code first and then giving the arguments for it. Even if the attacker passes a SQL command in the user input for a parameterized query, he will not be able to do so in the query's content.

Escaping User provided input

If dynamic queries cannot be avoided, escaping all user-supplied parameters is the best option. Then the developer should identify the all input sources to define the parameter that needs escaping, follow database-specific escaping procedures, and use standard defining libraries instead of the custom escaping methods.

Whitelisting/Blacklisting

The term "whitelist" refers to permitting only those words/characters in an input field that the developer has established. For example, most usernames do not contain special characters, hence special characters in the username field should be limited and It is not going to be accepted. Any additional submission or input will be ignored. The inverse of whitelisting is blacklisting, which refers to not allowing characters or words that have been defined in a developer's blacklist. Any input that is listed in the blacklist will be automatically eliminated or cause an error.

Data type validation

After completing the procedures for the parameterized query and escaping, the developer must ensure that the input data type is correctly validated. The developer must specify if the input data type is a string, numeric, or any other kind, and if the user's input data is erroneous, it will be easily rejected

Use the principle of least privilege

The idea of least privilege both avoids SQL injection attacks and mitigates their impact if they do occur. Instead of granting users access to the entire database, this strategy allows them to simply access the tables they require. They should also be given only the privileges they require, such as read-only, write-only, or read and write, depending on their needs. The concept of least privilege is a cornerstone of security, and it also applies to SQL injections. As a result, the impact of SQL injection is reduced because it only impacts one table or a set of tables rather than the entire database. In some circumstances, instead of allowing access to the entire table, a view for that piece of the table should be established.

References

• https://wikipedia.org
• https://google.com