Lab - DVWA SQL Injection
Objetivo: entender SQLi en entorno controlado. Ver SQL Injection.
Objetivo
Objetivo: entender SQLi en entorno controlado. Ver SQL Injection.
Resultados esperados (didácticos):
- Identificar un punto de inyección.
- Capturar evidencia reproducible (request/response + capturas).
- Entender por qué la parametrización evita SQLi.
- Traducir el aprendizaje a mitigación/detección en un entorno real.
Entorno (solo laboratorio)
Requisitos mínimos:
- DVWA corriendo localmente (o en VM aislada).
- Acceso a DVWA desde el navegador.
Recomendación de seguridad:
- Ejecuta DVWA en un entorno aislado (no expuesto a internet).
- Mantén credenciales y datos de prueba (nada real).
Opciones de despliegue (elige 1):
- Docker (rápido) o stack local (XAMPP/LAMP) según preferencia.
- Referencia: https://github.com/digininja/DVWA
Preparación
- Entra a DVWA y completa la configuración inicial (DB, usuario, etc.).
- Define el “Security Level” de DVWA (documenta cuál usas en evidencia).
- Abre el módulo vulnerable: “SQL Injection”.
Pasos (evidencias)
En este lab el objetivo no es “explotar a fondo”, sino entender la vulnerabilidad y documentarla correctamente.
1) Identificar el punto de entrada y el comportamiento base
- Interactúa con el formulario/endpoint con un input normal.
- Captura:
- Request/response (si usas proxy como Burp, guarda el raw).
- Captura de pantalla del resultado.
2) Señal de posible SQLi (prueba mínima)
- Introduce un input que fuerce un caso de error o comportamiento anómalo (ver señales en SQL Injection).
- Observa:
- ¿Cambia la respuesta? ¿Aparecen errores? ¿Se comporta distinto?
- Captura evidencia (request/response + UI).
3) Confirmación controlada (prueba booleana simple)
- Realiza una prueba booleana sencilla que cambie el resultado de forma visible (ver ejemplo educativo en SQL Injection).
- Documenta:
- Qué parámetro es vulnerable.
- Qué diferencia se observa en la respuesta.
- Qué evidencia respalda la conclusión.
4) Comparar niveles de seguridad (aprendizaje clave)
- Repite pasos (1)–(3) cambiando el “Security Level”.
- Objetivo:
- Ver cómo cambian los controles (validación/escape/parametrización).
- Identificar qué enfoque es realmente robusto (parametrización + mínimo privilegio).
- Si DVWA permite ver el código del módulo, anota:
- Dónde se construye la query.
- Si hay concatenación vs prepared statements.
Resultados (qué debe quedar escrito)
- Vector: parámetro vulnerable + endpoint.
- Evidencia mínima reproducible:
- Request/response (sanitizando si hay PII; en DVWA no debería existir).
- Capturas de pantalla.
- Explicación: por qué la construcción de la query es insegura y cómo se corrige.
- Mitigación propuesta: prepared statements + mínimo privilegio + manejo de errores.
- Detección propuesta: qué logs/alertas permitirían ver intentos.
Lecciones aprendidas
- La “prueba” sin evidencia (solo “funciona”) no sirve: siempre documentar request/response.
- El WAF puede ayudar, pero la mitigación principal es parametrización.
- Cambiar el “Security Level” permite entender defensas reales y falsas sensaciones de seguridad.
Próximos pasos
- Refuerza con:
- Crea (opcional) un “Finding” con plantilla: TEMPLATE__Finding
Evidencias
- Capturas:
- Requests: (pegar raw aquí o adjuntar export de Burp)