Understanding SQL Injection: From Basics to Blind Exploitation
A deep dive into SQL injection vulnerabilities, how they work, how attackers chain them into full database compromise, and the detection signatures every defender should know.
Introduction
SQL injection remains one of the most exploited vulnerability classes on the web, not because defenders don't know about it, but because it keeps appearing in codebases written by developers who underestimate its reach. After spending time testing applications across multiple industries, I can say with confidence that SQLi is rarely just a database read. When chained correctly, it becomes a full compromise vector.
How SQL Injection Works
At its core, SQL injection occurs when user-supplied input is concatenated directly into a SQL query without proper sanitization. Consider a login form that constructs a query like this:
SELECT * FROM users WHERE username = '$input' AND password = '$pass'An attacker supplying ' OR '1'='1 as the username causes the query to return all users, bypassing authentication entirely.
Types of SQL Injection
In-band SQLi returns results directly in the application response. This is the most straightforward to exploit and detect.
Blind SQLi returns no data but allows an attacker to ask true/false questions about the database. Boolean-based blind injection works by observing whether the application behaves differently based on injected conditions.
Time-based blind SQLi uses database sleep functions to infer data when no output difference is visible. A payload like '; IF (1=1) WAITFOR DELAY '0:0:5'-- on MSSQL will cause a 5-second delay if the condition is true.
Out-of-band SQLi exfiltrates data through DNS or HTTP requests, useful when in-band channels are blocked.
Exploitation Chain
In a real engagement, SQLi rarely stops at data extraction. From a vulnerable parameter I was able to:
- Enumerate database version and schema
- Extract credential hashes from the users table
- Crack MD5 hashes offline using a wordlist
- Log in to the admin panel with cracked credentials
- Upload a webshell via file upload functionality
- Pivot to internal network resources
Detection and Prevention
From a blue team perspective, look for these patterns in WAF and application logs:
- Single quotes and comment sequences such as
--,#, and/* UNION SELECTstrings in request parameters- Unusual response time spikes on database-heavy endpoints
Prevention is straightforward. Use parameterized queries or prepared statements. ORMs help but are not a silver bullet. Always validate input on the server side regardless of client-side controls.
Conclusion
SQL injection is a 25-year-old vulnerability class that still appears in production systems daily. Understanding the full exploitation chain, not just the first step, is what separates a thorough security assessment from a checkbox exercise.