Thread by @e11i0t_4lders0n

SQLi Manual Approach

Thread 🧵

#bugbounty #bugbountytip #bugbountytips

First thing to test for an SQL injection is to try to break the query,with the intention of getting the syntax of how SQL is getting input at the backend.This technique works in UNION/Error based SQL Injections,where we force the backend database to throw an error.

Using this technique,we can somehow determine the backend query structure to efficiently exploit SQL Injection.Query can be broken by throwing various characters as input.

Afterwards an escape character \ can be used just to make sure what is breaking the query.Once it is guessed how exactly SQL is taking input, we’ll try to break and then fix the query.

This step is necessary to determine where we can put our own malicious query, that will be executed at the backend.

The query can be fixed in some of the ways below:
‘’    --+
‘    --+
‘’    #
‘     \*    *\
‘    -- -
'     or    '1

To know what DBMS is running at the backend, error messages can tell a lot,

But in the case of Blind Injections, another way is to determine through different numeric functions like:

Oracle: BITAND(1,1)
MySQL: POW(1,1)
SQL Server: SQUARE(1,1)

For example if “list.php?id=8” and “list.php?id=9- POW(1,1)” is returning the same output,it means MySQL is running at the backend.

Every DBMS uses different concatenation operators to store text input
Eg:

Oracle:  'que' || 'ry’
MySQL: ‘que’ ‘ry’
SQL Server: ‘que’ + ‘ry’

For example if “id=query” and “id=’que’ || ‘ry’”  is returning the same output, it means Oracle is running at the backend.

Then you can try for union based, error based , blind, out of band

I will publishing one blog on SQLi on medium