Skip to content

SQLi - SQL Injection

Some vulnerabilities whisper.
SQLi shouts. It doesn’t just leak data. It rewrites the rules of how data is accessed, stored, and protected.
It’s not about clever tricks. It’s about understanding how applications talk to their databases, and how that conversation can be hijacked.

What this page covers

  • What SQLi is: the concept, the mechanics, and the impact
  • How to exploit it: payloads, techniques, and real-world examples
  • How to defend against it: parameterization, validation, and design
  • How to detect it: signs, tools, and testing strategies
  • How I’ve practiced it: labs, notes, and personal experiments

This isn’t just about breaking databases.
It’s about understanding how trust flows between layers, and how it can be broken.

What SQLi Actually Is

SQL Injection (SQLi) is a vulnerability that allows an attacker to manipulate SQL queries by injecting malicious input into application fields.
If the application fails to properly sanitize or parameterize user input, that input becomes part of the query logic and the attacker gains control.

The Core Idea:

User input is inserted directly into a SQL query without proper handling.
The attacker can then modify the query to return unauthorized data, bypass authentication, or even write to the database.

Common Examples

  • Login bypass: ' OR '1'='1
  • Data extraction: UNION SELECT username, password FROM users
  • Blind injection: using timing or boolean responses to infer data
  • Error-based injection: triggering verbose SQL errors to reveal structure
  • Out-of-band injection: using DNS or HTTP callbacks to exfiltrate data

SQLi is often found in:

  • Login forms
  • Search bars
  • URL parameters
  • Hidden fields
  • API endpoints

What Happens When It’s Exploited

  • Unauthorized access to sensitive data
  • Full database dumps
  • Bypassing authentication
  • Modifying or deleting records
  • Gaining shell access via stacked queries or file writes
  • Persistent compromise if used to plant backdoors

SQLi doesn’t just expose data.
It gives attackers the ability to reshape it.

How to Mitigate SQLi

1. Use Parameterized Queries

Never build SQL strings by concatenating user input.
Use prepared statements with placeholders.

2. Validate Input

Reject unexpected characters and enforce strict types.
Don’t rely on client-side validation alone.

3. Limit Database Privileges

Use accounts with the least privilege necessary.
Don’t let the web app connect as a root or admin user.

4. Monitor and Log Queries

Track unusual query patterns and failed login attempts.
Use anomaly detection where possible.

5. Use ORM Safely

Object-relational mappers can help, but only if used correctly.
Avoid raw queries unless absolutely necessary.

Mitigation is about separating logic from input.
The query should never trust the user.

How I Practice SQLi

I use labs like:
- Hack The Box: Academy and challenges
- PortSwigger Web Security Academy
- TryHackMe: SQLi playgrounds
- DVWA and Juice Shop in my homelab

I test:
- Classic payloads and login bypasses
- UNION-based extraction
- Blind injection with timing and boolean logic
- Error-based techniques
- Out-of-band methods using Burp Collaborator

Every time I exploit SQLi, I learn something about how applications trust their users and how dangerous that trust can be.

Final Thought

SQLi is one of the oldest vulnerabilities in the book.
But it’s still one of the most powerful.
It teaches how deep a single input field can go, and how much damage it can do when left unchecked.

This page is my study of that depth.
Not just how to exploit it, but how to understand it, prevent it, and explain why it still matters.