SQL Injection : An Introduction

SQL Injection

What is SQL injection?

SQL injection is a web vulnerability that enables an attacker to interfere with the requests made by a web application to a database via some input fields, where the payloads are written. This interference can lead to exposure of sensitive data that are not to be disclosed publicly such as PII, and in few cases can also enable the attacker to modify or delete data from the database, which can alter the application’s content and behavior.

How to detect SQL injection vulnerabilities

The possible fields in a web application where SQLi could be possible are search fields, login and sign up forms and also other input fields, any item from where an application could query a database.

Methods to detect possibility of SQLi:

• Placing a single quote ' character and look for errors or other anomalies.
• Meddling with the values of endpoints to check for changes in the applications functioning.
• Boolean conditions such as OR 1=1 or OR 1=2 , and look for differences in the responses.
• Payloads that trigger time delays along with conditional expressions in SQL queries can help us to identify possible changes in application’s responses.
• OAST payloads to trigger out-of-band network interaction when executed within a SQL query, and monitor any resulting interactions.

SQL Injection Example

SQLi can be exploited in different parts of a query other than the WHERE clause of a SELECT statement. They are:

• In UPDATE statements, within the updating values or the WHERE clause.
• In INSERT statements, within the inserted values.
• In SELECT statements, within the table or column name.
• In SELECT statements, within the ORDER BY clause.

For an example of SQLi, consider a web application at the following URL having the endpoint products which takes an input value category:

https://insecure-site.com/products?category=Gifts

This causes the web application’s back-end to run the following SQL query:

SELECT * FROM products WHERE category='Gifts' AND released = 1;

From the above SQL query what we can understand is that:

• All data from the products table of only the Gifts category
• released=1 states the information of only released products is to be returned. The restriction applied byreleased=1 blocks a normal user to view unreleased products.

But an attacker could perform an SQLi by using the payload ' -- concatenated to the category field. Then the request URL looks like: https://insecure-site.com/products?category=Gifts'--

Due to which the SQL query changes to:

SELECT * FROM products WHERE category='Gifts'--' released=1

The -- operator in SQL denotes a comment, meaning that in the above query everything after the -- gets commented out and is not considered for evaluation which leads to the retrieval of all products, both released and unreleased, of the category Gifts.

What if we want to retrieve all products irrespective of category. Then we can add a boolean condition that always evaluates to true such as OR 1=1 to the payload. The request URL would then be:

https://insecure-site.com/products?category='Gifts'+OR+1=1--

Then the SQL query would be:

SQL * FROM products WHERE category='Gits' OR 1=1 --' released =1

The query retrieves all products where category is Gifts or when 1=1, which is always true, leading the application to retrieve products of all categories. And also, because of the -- commenting both released and unreleased product details will be retrieved.

NOTE: Using the conditional statement OR 1=1 is not always suggested because if used with either an UPDATE statement or a DELETE statement, it can lead to modification or deletion of data.

Another example of login bypass

Suppose a web application has a login page. The general procedure of validating a user by using his username and password involves sending the following SQL query to a database:

SELECT * FROM users WHERE username='cyberknight' AND password='s3CrEt'

Now as we previously discussed, we could use the commenting payload'-- to bypass the login function. We can append the payload to the username field as such: cyberknight'-- and some random text in the password field causing the application to run the following modified query:

SELECT * FROM users WHERE username='cyberknight' -- AND password='asdfasdf'

Now what this means is that the database retrieves the details just if the username actually exists without checking the password.

What if you do not know the username also? In such a case, we could use the boolean conditional payload' OR 1=1-- to login the application. In such cause, the query would be modified as:

SELECT * FROM users WHERE username='asdfasdf' OR 1=1 -- AND password='asdfasdf'

The above queries retrieves all users' details from the users table allowing the application to login irrespective of the username.

But there is a race condition. What if the applications back end after receiving the SQL queries response, checks the retrieved number of rows and if found to be more than 1, deletes all of the users details assuming them to be duplicates of the same username, causing you to lose all user data from the database, making it a loss for both the attacker and the user. So, use this payload with caution.

I will be blogging regularly with interesting content. I am a student, so it is tough to keep up with everything. Please keep supporting.