SQL Injection

SQL Injection, or SQLI is a means to attack a website or server, with the intention of manipulating the back-end and database to run malicious queries as per desire of the attacker.

Although SQL Injection is an aged form of cyber attack, and most systems likely have taken measures against this - it often does not end up being the case. It can be caused by lack of priority or planning, but plenty of systems even today implement security measures but overlook the possibilities of SQL injections. As a developer, it is natural to have come across the term SQLI or SQL Injection fairly frequently. However, most of the time, the preventive measures are taken against this type of attack without actually understanding what the attacker is doing or trying to do.

In this article, I will provide a very simple example of a log in system that is vulnerable to SQL Injection, and how the SQL Injection can actually be done to allow the attacker into the system without having the correct user password.

A Simple Example

To understand the tutorial effectively, some basic understanding of the following topics is expected:

• SQL
• JavaScript (Basic Client Side Web Programming)

Let's take a look at the query we will be using throughout the tutorial:
SELECT * FROM users WHERE email = <email> $email AND password = <password>

This query will be executed in the example using PHP to check for a user with the email and user provided from the client.

Here is a simple log in form, and for demonstration purposes, the query that is expected to be executed is shown above it. This will help visualize exactly what is going on.

On the first attempt, the wrong credentials are entered, and the message is shown accordingly below the form. In a scenario where you do not know the password, this is where things would stop on your end. However, with SQL Injection, things can be made out to be more interesting.

The Injection Step

Remember that with most SQL queries, there will be single quotes that wrap the data that is being queried against, such as 'john.doe@gmail.com' and 'Admin@123' in this example. A system vulnerable to SQL injections will be unable to handle a scenario where SQL syntaxes are entered into the inputs themselves.

On first read, it may seem like much has not changed. However, if a closer look is taken at the network tab of the browser, it can be seen that the error message has changed drastically. The single quote after the email field has tossed the server into disarray, because it was not expecting the single quote (or any SQL syntax for that matter). Note exactly how the query in the browser above the form has also changed, and it ultimately has broken the query.

This tells us that we can manipulate the input field in a way that lets us inject SQL directly into code of the server. Now we can proceed to how this can get malicious.

If we try using SQL logic to beat the system, the process becomes a cakewalk. Suppose you want to add a logic to add to the existing query that is always going to be true no matter what - such as '0'=='0', because zero will always be equal to zero! By default, SQL will look at AND statements before looking at the OR. Using this to our advantage, we can add ' OR '0'=='0' in the email field.

Not surprisingly enough, the authentication has been bypassed and the user has been logged into the system without ever providing a correct password. So what did actually happen? Well, if we were to take a look at the query we created by injecting the SQL into the email field, this is what we get from the screenshot above: SELECT * FROM users WHERE email = 'john.doe@gmail.com' OR '0'='0' AND password = 'Admin@123'

This means that the AND operator will try to execute, and fail at first, but then when the OR operator executes, it essentially only checks if the email is matching OR if the statement '0' = '0' is occurring or not, which as mentioned earlier, will always be true. This way, this SQL statement will end up being true in every single scenario regardless of whether the password matches or not, as the OR statement will execute with a condition that will always be true, and ultimately result in a truthy result no matter what.

Another approach

Here's another way for this example:

Once again, this time in much simpler fashion, the authentication has been bypassed. Remember that -- is actually considered as a comment in most SQL systems, and therefore in this example, the final query is just the email field being checked, and the password field being completely ignored.

This was a simple example of how In-band Error-based SQL Injection can work, and there are other types such as Inferential (Blind) SQLi and Out-of-band SQLi. Although most of the cyber world always takes measures against these kinds of attacks, its always important to remember that what may be seen as a low priority in a security measure is always most likely going to be used by hackers and attackers. Prepared Statements on the server-end are among the easiest and simplest ways to avoid vulnerability to SQL injections.

Please remember that the purpose of this tutorial is strictly educational, and not at all to promote any sort of illegal activities. It is important for a developer to know how attacks actually happen, in order to take measurements against them.

This example is done with HTML, CSS, JavaScript and PHP on the server-side.
Github source code: https://github.com/snigdho611/sql-injection