Inyección SQL Ciega (Blind SQL Injection)

Cómo Funciona Inyección SQL Ciega (Blind SQL Injection)

A diferencia de la inyección SQL clásica donde los mensajes de error o los resultados de la consulta aparecen en la respuesta, la inyección SQL ciega explota aplicaciones que suprimen por completo la salida de la base de datos. La vulnerabilidad existe cuando la entrada del usuario se concatena en consultas SQL sin parametrización — la misma causa raíz que la SQLi clásica — pero la técnica de explotación difiere fundamentalmente. El atacante debe construir preguntas binarias sobre la base de datos e interpretar el comportamiento de la aplicación como respuestas de 'sí' o 'no', lo que hace la extracción más lenta pero igualmente devastadora.

Ejemplos Reales

Impacto y Evaluación de Riesgo

La inyección SQL ciega tiene el mismo impacto catastrófico que la inyección SQL clásica — compromiso total de la base de datos — pero a menudo es más peligrosa porque evade el monitoreo de seguridad básico. Dado que no se generan mensajes de error y las consultas parecen sintácticamente válidas, la SQLi ciega puede operar sin ser detectada durante períodos prolongados. Los atacantes pueden extraer bases de datos completas incluyendo credenciales, datos personales, registros financieros y claves de cifrado. En casos severos, la SQLi ciega permite la ejecución de comandos en el servidor de base de datos (mediante xp_cmdshell en SQL Server o INTO OUTFILE en MySQL), pasando del robo de datos al compromiso total de la infraestructura. Las organizaciones enfrentan sanciones regulatorias bajo GDPR, PCI DSS, HIPAA y CCPA, junto con daño reputacional, responsabilidad legal e interrupción del negocio.

Cómo Detectar Inyección SQL Ciega (Blind SQL Injection)

La inyección SQL ciega es inherentemente más difícil de detectar que la SQLi clásica porque no genera errores de base de datos visibles en los logs de la aplicación. Monitorear patrones sospechosos: altos volúmenes de solicitudes similares con ligeras variaciones en los parámetros (característico de la extracción automatizada), solicitudes que contienen expresiones condicionales SQL (IF, CASE, WHEN), funciones de manipulación de tiempo (SLEEP, WAITFOR DELAY, BENCHMARK, pg_sleep), y funciones de extracción de subcadenas (SUBSTRING, MID, ASCII, ORD). Analizar las distribuciones de tiempos de respuesta — la inyección ciega basada en tiempo crea patrones bimodales distintivos con algunas respuestas retrasadas por intervalos exactos (ej., exactamente 5 segundos). Desplegar monitoreo de actividad de base de datos (DAM) para detectar patrones de consulta inusuales, particularmente consultas con lógica condicional que referencian tablas del sistema (information_schema, sys.tables). Las reglas del WAF deben detectar variantes codificadas y ofuscación basada en comentarios (/*!SLEEP(5)*/, %53%4C%45%45%50).

Cómo Prevenir Inyección SQL Ciega (Blind SQL Injection)

Usar consultas parametrizadas (sentencias preparadas) para todas las interacciones con la base de datos — esto elimina la inyección SQL por completo independientemente de la variante. Aplicar validación estricta de entrada con listas blancas para los tipos de datos y formatos esperados. Implementar el principio de mínimo privilegio: las cuentas de base de datos utilizadas por la aplicación deben tener permisos mínimos (solo SELECT donde no se necesitan escrituras, sin acceso a information_schema o procedimientos almacenados del sistema). Usar frameworks ORM que manejan la parametrización automáticamente. Desactivar mensajes de error detallados en producción — aunque esto no previene la inyección, obliga a los atacantes a usar técnicas ciegas más lentas. Implementar tiempos de espera en la ejecución de consultas para limitar la extracción basada en tiempo. Desplegar un WAF con detección de inyección SQL que cubra patrones específicos de inyección ciega, incluyendo funciones de tiempo y expresiones condicionales basadas en booleanos. Realizar pruebas de penetración regulares con herramientas como sqlmap para identificar vulnerabilidades antes que los atacantes.

Ejemplos de Código

# 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) --

Preguntas Frecuentes

Ataques Relacionados