OWASP A05:2025 · CWE-89

SQLi —
Amenaza
Persistente

Laboratorio didáctico interactivo. Comprende cómo los atacantes identifican, explotan y extraen datos mediante SQL Injection — y cómo mitigarlo.

Superficie Expandida Código IA Vulnerable Legacy sin Parchar Mitigación Práctica
Iniciar Laboratorio Ver Defensas
0%
apps afectadas
0
años activo
0+
CVEs SQLi
gr58@lab:~$ sqlmap [simulation]
UNION-Based SQLi
2841 registros expuestos
SIMULACIÓN 01

Superficie Expandida

Selecciona cada vector para ver el payload, la query vulnerable y la mitigación. Luego practica el ataque paso a paso en el laboratorio.

Formulario
CRÍTICO
REST API
CRÍTICO
HTTP Headers
ALTO
Cookies
MEDIO
GraphQL
CRÍTICO
Código IA
CRÍTICO
Laboratorio — Ataque Paso a Paso INTERACTIVO
01 Recon
02 Sondeo
03 Confirmar
04 Extraer
05 Defender
SIMULACIÓN 02

Código IA Vulnerable

El "vibe coding" genera queries con concatenación directa. Escanea el código, detecta vulnerabilidades SQLi y aplica la corrección.

Código Generado por IA AI-GENERATED
Resultados del Análisis
Ejecuta el análisis para ver
las vulnerabilidades detectadas
¿POR QUÉ EL CÓDIGO IA ES VULNERABLE?
Los LLMs aprenden de repositorios con código inseguro. Generan f-strings, template literals y concatenación directa — los patrones que causan SQLi. Sin revisión SAST, este código llega a producción. Trend Micro (2025) documenta el "vibe coding" como vector emergente de SQLi en 2026.
SIMULACIÓN 03

Legacy sin Parchar

Escanea sistemas legacy empresariales. Identifica deuda técnica crítica: PHP antiguo, Java con raw queries, ORMs mal configurados.

Inventario de Sistemas 4 SISTEMAS
Reporte de Vulnerabilidades
Selecciona un sistema para
iniciar el análisis
0%+
de apps cerradas con SQLi al primer análisis
0
puntos de inyección promedio por codebase
0
días promedio para detectar una brecha activa
DEFENSA

Cómo Mitigar SQLi

Controles técnicos probados. La defensa primaria es siempre código — WAF es solo capa adicional.

1. Prepared Statements

Separa código SQL de datos. La BD compila el template primero; los parámetros son datos, nunca código.

# Python seguro cursor.execute( "SELECT * FROM users WHERE id=%s", (user_id,))
DEFENSA PRIMARIA

2. Validación Allow-list

Para campos con formato conocido, rechazar todo lo que no coincida con el patrón esperado antes de tocar la BD.

# Validar tipo estricto try: uid = int(request['id']) except: abort(400)
DEFENSA SECUNDARIA

3. Mínimo Privilegio

La cuenta de app solo tiene los permisos mínimos. Nunca root/sa. Sin acceso a information_schema.

-- Solo permisos necesarios GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'appuser' -- SIN: DROP, FILE, SUPER
CONFIG BD

4. Suprimir Errores

Mensajes de error de BD revelan estructura interna. En producción siempre mensajes genéricos al cliente.

except Exception as e: log.error(e) # solo interno return "Error interno" # nunca: str(e)
PROD CRÍTICO

5. WAF + SAST

WAF como segunda capa. SAST en pipeline CI/CD para detectar vulnerabilidades antes de producción.

ModSecurity CRS 3.3+
Semgrep / SonarQube SAST
OWASP ZAP en staging
DEVSECOPS

6. Auditoría Periódica

Pentest SQLi al menos anualmente. Usar DVWA y sqlmap en staging para validar defensas antes de cada release.

sqlmap --level=5 --risk=3
DVWA Low → Impossible
Informe formal de pentest
PROCESO
Simulador de Defensa — ¿El ataque funciona con código seguro? PRUEBA FINAL

Ingresa cualquier payload SQLi conocido. El sistema con prepared statements lo bloqueará sin importar el payload.

El resultado aparecerá aquí