The underlying principle of SQL Injection Attack

Sankeerth Mahurkar
4 min readMay 8, 2020

Hello everyone, this story is a brief introduction to the underlying principle of SQL Injection Attack.

SQL Injection attack, also known as SQLi attack, is one of the most common, easiest, and most dangerous form attack that is performed on SQL Databases.

A Relational Database Management System (RDBMS)functions primarily based on what is being queried. It never attempts to check if the query is malicious or not. It just responds to what is being queried.

Forming the above statement as the basis, this attack injects other malicious code within a SQL query that leads to potential damage to the database and tampering of data.

What is the origin of this attack?

This vulnerability arises where query parameter values are inputted from users. For example, in a login form, the attacker may input some malicious query in the input fields. These malicious codes might also be passed as API or URL parameters.

So now let us what happens when such malicious code is entered.

Let’s construct a scenario first

Consider a database with the tables in the following image. This is our test database, with the following architecture provided by MySQL.

Image -1 . Source: https://github.com/datacharmer/test_db

Recall what is SQL injection, I have said it is injecting malicious query within a SQL query right? Now let’s see how.

Consider a SQL query as SELECT * FROM `employees` WHERE `emp_no` = ‘10001’ . It will give the following result.

Image — 2A. Result of SELECT * FROM `employees` WHERE `emp_no` = ‘10001’

Now let us replace the value 10001 with 1000’ OR 1=1# . Now our query becomes SELECT * FROM `employees` WHERE `emp_no` = ‘10001’ OR 1=1#’ and this query will indeed result as following

Image — 2B. Result of SELECT * FROM `employees` WHERE `emp_no` = ‘10001’ OR 1=1#’

So you can see how different these things, are we intended to fetch one record instead this query fetched almost entire table.

Now let me explain what just happened. The first query is common and straightforward. The second query is a bit tricky. Instead of passing a single value, we passed a part of the query.

  1. 10001' closes the value part.
  2. OR is an operator
  3. 1=1 is a condition that is always true.
  4. And # because of another ' that has left out, we will just comment it.
  5. So the query ultimately means no matter what the hell emp_no is, just fetch entire records, because 1=1 is always true.

Note: # doesn’t work with all the Databases same way, some databases use — - (double hyphen) as comment. While some may use null characters it completely depends on the Database being used.

So in this way attackers can inject some unintentional malicious code and tamper query before execution. And you can see how unintentionally query gets changed right?

Now let us see another example. In this example, we will try to fetch the records from another table departments. So, for this, we will use UNION statement and query follows as SELECT `emp_no`, `first_name` FROM `employees` WHERE `emp_no` = ‘10001’ UNION SELECT * FROM `departments` #’ . The result will be

Image — 2B. Result SELECT `emp_no`, `first_name` FROM `employees` WHERE `emp_no` = ‘10001’ UNION SELECT * FROM `departments` #’

In the above example, malicious code injected was 10001’ UNION SELECT * FROM `departments` # . This was an example of Union based SQL Injection.

Conclusion:

So this was the underlying principle of SQLi attack. The goal is to somehow change the SQL query into a malicious one before it gets executed. And the successful execution of this malicious query leads to a successful attempt.

Please refer to the links in references to know more about this attack more comprehensively.

--

--