Blind SQL Injection

How Blind SQL Injection Works

Unlike classic SQL injection where error messages or query results appear in the response, blind SQL injection exploits applications that suppress database output entirely. The vulnerability exists whenever user input is concatenated into SQL queries without parameterization — the same root cause as classic SQLi — but the exploitation technique differs fundamentally. The attacker must construct binary questions about the database and interpret the application's behavior as 'yes' or 'no' answers, making extraction slower but equally devastating.

Real-World Examples

Impact & Risk Assessment

Blind SQL injection carries the same catastrophic impact as classic SQL injection — complete database compromise — but is often more dangerous because it evades basic security monitoring. Since no error messages are generated and queries appear syntactically valid, blind SQLi can operate undetected for extended periods. Attackers can extract entire databases including credentials, personal data, financial records, and encryption keys. In severe cases, blind SQLi enables command execution on the database server (via xp_cmdshell on SQL Server or INTO OUTFILE on MySQL), pivoting from data theft to full infrastructure compromise. Organizations face regulatory penalties under GDPR, PCI DSS, HIPAA, and CCPA, along with reputational damage, legal liability, and business disruption.

How to Detect Blind SQL Injection

Blind SQL injection is inherently harder to detect than classic SQLi because it doesn't trigger database errors visible in application logs. Monitor for suspicious patterns: high volumes of similar requests with slight parameter variations (characteristic of automated extraction), requests containing SQL conditional expressions (IF, CASE, WHEN), time-manipulation functions (SLEEP, WAITFOR DELAY, BENCHMARK, pg_sleep), and substring extraction functions (SUBSTRING, MID, ASCII, ORD). Analyze response time distributions — time-based blind injection creates distinctive bimodal patterns with some responses delayed by exact intervals (e.g., exactly 5 seconds). Deploy database activity monitoring (DAM) to flag unusual query patterns, particularly queries with conditional logic that reference system tables (information_schema, sys.tables). WAF rules should detect encoded variants and comment-based obfuscation (/*!SLEEP(5)*/, %53%4C%45%45%50).

How to Prevent Blind SQL Injection

Use parameterized queries (prepared statements) for all database interactions — this eliminates SQL injection entirely regardless of variant. Apply strict input validation with allowlists for expected data types and formats. Implement the principle of least privilege: database accounts used by the application should have minimal permissions (SELECT only where writes aren't needed, no access to information_schema or system stored procedures). Use ORM frameworks that handle parameterization automatically. Disable verbose error messages in production — while this doesn't prevent injection, it forces attackers to use slower blind techniques. Implement query execution timeouts to limit time-based extraction. Deploy a WAF with SQL injection detection that covers blind-specific patterns including time functions and boolean-based conditional expressions. Conduct regular penetration testing with tools like sqlmap to identify vulnerabilities before attackers do.

Code Examples

# Detecting boolean-based blind SQLi attempts in logs
import re

BLIND_SQLI_PATTERNS = [
    r"AND\s+\d+=\d+",                    # AND 1=1, AND 1=2
    r"AND\s+SUBSTRING\s*\(",             # AND SUBSTRING(...)
    r"AND\s+ASCII\s*\(",                 # AND ASCII(...)
    r"AND\s+ORD\s*\(",                   # AND ORD(...)
    r"AND\s+IF\s*\(",                    # AND IF(...)
    r"AND\s+CASE\s+WHEN",               # AND CASE WHEN...
    r"AND\s+\(SELECT\s+COUNT",           # AND (SELECT COUNT...
    r"ORDER\s+BY\s+\d+",                # ORDER BY column enumeration
]

def detect_blind_sqli(request_params):
    """Check request parameters for blind SQLi patterns"""
    for param_name, param_value in request_params.items():
        for pattern in BLIND_SQLI_PATTERNS:
            if re.search(pattern, param_value, re.IGNORECASE):
                return {
                    'detected': True,
                    'parameter': param_name,
                    'pattern': pattern,
                    'value': param_value
                }
    return {'detected': False}

import psycopg2

# VULNERABLE: String concatenation allows blind SQLi
def get_user_vulnerable(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    # Attacker input: 1 AND (SELECT CASE WHEN (username='admin')
    #   THEN pg_sleep(5) ELSE pg_sleep(0) END FROM users LIMIT 1)
    cursor.execute(query)
    return cursor.fetchone()

# SECURE: Parameterized query prevents all SQL injection
def get_user_secure(user_id):
    query = "SELECT * FROM users WHERE id = %s"
    cursor.execute(query, (user_id,))
    return cursor.fetchone()

# SECURE: Input validation + parameterized query
def get_user_validated(user_id):
    if not isinstance(user_id, int) or user_id < 1:
        raise ValueError('Invalid user ID')
    query = "SELECT * FROM users WHERE id = %s"
    cursor.execute(query, (user_id,))
    return cursor.fetchone()

-- Boolean-based: Different response for true vs. false
-- True condition (normal response)
' AND 1=1 --
-- False condition (different response)
' AND 1=2 --

-- Extract database version character by character
' AND SUBSTRING(@@version,1,1) = '5' --
' AND ASCII(SUBSTRING(@@version,1,1)) > 53 --

-- Time-based: Measurable delay when condition is true
-- MySQL
' AND IF(1=1, SLEEP(5), 0) --
-- PostgreSQL
' AND (SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END) --
-- SQL Server
'; WAITFOR DELAY '0:0:5' --

-- Extract table names via time-based
' AND IF(
  (SELECT SUBSTRING(table_name,1,1)
   FROM information_schema.tables
   WHERE table_schema=database() LIMIT 1) = 'u',
  SLEEP(5), 0) --

Frequently Asked Questions

Related Attacks