Tutorial de DVWA: La guía para el hacking ético

Es probable que hayas oído hablar de vulnerabilidades XSS, inyección SQL o pentesting, sin saber exactamente por dónde empezar o cómo proceder de manera correcta. Existe una herramienta diseñada para el aprendizaje controlado en un entorno local y sin riesgos. Su nombre es deliberadamente provocador: DVWA, acrónimo de Damn Vulnerable Web Application.

DVWA es un entorno de entrenamiento diseñado específicamente para demostrar cómo funcionan las vulnerabilidades web y, fundamentalmente, cómo prevenirlas. DVWA funciona como un laboratorio de pentesting controlado para desarrolladores y profesionales de la seguridad; una manera de practicar de forma segura dentro de los límites legales y éticos de la seguridad informática.

En este tutorial de DVWA, te guiaré paso a paso, desde cero, con explicaciones precisas, ejemplos concretos y una metodología de entrenamiento estructurada. Aprenderás:

• Comprender la finalidad de DVWA y su uso seguro para el aprendizaje de la seguridad web de manera legal y controlada.
• Implementar un entorno de entrenamiento local y seleccionar los ajustes adecuados para progresar sin dificultad.
• Desarrollar los procedimientos técnicos para identificar las vulnerabilidades más comunes y entrenar eficazmente con ejercicios prácticos.

El objetivo no es simular ser un hacker malicioso, sino comprender la seguridad web para desarrollar código de manera más robusta, segura y profesional utilizando DVWA.

¿Qué es DVWA exactamente?

DVWA son las siglas de Damn Vulnerable Web Application. Su traducción al español es “Aplicación Web Condenadamente Vulnerable”. El nombre es intencionadamente directo: DVWA es un sitio web que contiene un gran número de vulnerabilidades de seguridad implementadas de forma deliberada.

Es una aplicación web PHP/MySQL deliberadamente vulnerable, diseñada como un entorno de entrenamiento para que profesionales de la seguridad y desarrolladores aprendan sobre vulnerabilidades web. Permite practicar la identificación y explotación de fallos como XSS o inyección SQL en un entorno legal, seguro y controlado.

Esta aplicación PHP opera con una base de datos MySQL (o MariaDB). Una vez ejecutada, presenta la interfaz de un pequeño sitio web con un menú y varias páginas. En estas páginas, encontrarás vulnerabilidades conocidas del mundo real: fallos de XSS, inyecciones SQL, problemas de control de acceso, subidas de archivos peligrosas, CSRF, etc.

Por lo tanto, no es un “juego” en el sentido convencional. Es un laboratorio. Un entorno en el que tienes permitido probar, fallar, reiniciar y, sobre todo, comprender.

DVWA es ampliamente utilizado por principiantes en ciberseguridad, así como por desarrolladores web que buscan aprender a securizar sus aplicaciones o revisar los fundamentos del OWASP Top 10. DVWA es un proyecto reconocido, referenciado dentro del ecosistema OWASP y listado en el OWASP Vulnerable Web Applications Directory (VWAD).

La principal ventaja de DVWA es que no es una herramienta teórica. No estás leyendo una definición en un curso; te enfrentas al comportamiento real de un código vulnerable. Observas los efectos, identificas los errores y aprendes a dominar el lenguaje técnico de la seguridad web.

¿Cuál es la utilidad concreta de DVWA?

DVWA sirve para aprender sobre seguridad web en condiciones realistas, pero dentro de un marco legal. En la práctica, te ayuda a comprender cómo se origina una vulnerabilidad, cómo se detecta y por qué representa un riesgo.

La mayoría de las vulnerabilidades no son el resultado de técnicas complejas. Se originan a partir de un principio simple: la aplicación confía excesivamente en la entrada del usuario. Un campo de formulario, un parámetro de URL, una cookie, un archivo subido… todos estos son puntos de entrada. Cuando no se filtran o no se controlan adecuadamente, el usuario puede realizar acciones no previstas. A veces sin intenciones maliciosas, otras veces con un propósito definido.

DVWA también sirve para aprender a protegerse. Esto es fundamental: un pentest serio no es una demostración de fuerza, sino un proceso de prevención. El objetivo final es siempre la corrección de las fallas.

Si administras un sitio web, desarrollas una aplicación o impartes formaciones, DVWA te proporciona una visión clara de los peligros. A partir del momento en que observas estos riesgos en un entorno real, tu enfoque de programación integrará una capa adicional de vigilancia.

¿Cómo funciona DVWA?

DVWA es una aplicación web PHP. Esto significa que se ejecuta en un servidor web (generalmente Apache), procesa código PHP en el lado del servidor y almacena ciertos datos en una base de datos MySQL/MariaDB.

Para su instalación, necesitas un entorno que proporcione: un servidor Apache, un intérprete de PHP y una base de datos MySQL.

Una vez instalado, DVWA ofrece una interfaz web. Te conectas (con las credenciales por defecto), seleccionas el nivel de seguridad y accedes a los módulos de vulnerabilidades.

Cada módulo ilustra una vulnerabilidad específica. Por ejemplo, en un módulo XSS, la aplicación tomará un dato del usuario y lo mostrará sin filtrado. En un módulo de inyección SQL, construirá una consulta SQL concatenando una entrada del usuario sin protección. Es aquí donde se observa la diferencia entre la teoría y la realidad operativa.

Es análogo a un entorno de simulación donde es posible cometer errores y repetir procedimientos sin consecuencias en un sistema de producción real.

Marco Legal y Ético: La Regla de Oro Antes de Empezar

Antes de realizar cualquier prueba fuera de tu entorno local, debes obtener permiso explícito y por escrito del propietario del sistema o aplicación a evaluar. Practicar pruebas de penetración sin autorización es ilegal en la mayoría de jurisdicciones y puede acarrear sanciones civiles o penales. (Esta regla se aplica incluso si tus intenciones son educativas.)

DVWA es vulnerable por diseño. Por lo tanto, si lo instalas en un servidor accesible desde Internet, estarás exponiendo una plataforma con vulnerabilidades conocidas a cualquier atacante.

DVWA debe utilizarse siempre en un entorno local, en una máquina virtual aislada o en un contenedor. Jamás en un hosting público. Jamás. Ni siquiera “solo para probar”.

Es importante enfatizar este punto, ya que ocurre con más frecuencia de lo que se cree: usuarios instalan DVWA en un VPS pequeño, asumiendo que “nadie lo encontrará”, y tres días después se preguntan por qué su servidor está siendo utilizado para minar criptomonedas.

Repito: DVWA es un entorno de entrenamiento, no un sistema para ser expuesto públicamente.

Cómo Instalar DVWA Localmente: Guía Paso a Paso

Existen varios métodos para instalar DVWA. La elección más simple para un principiante dependerá de su sistema operativo. El principio general es el mismo: obtener DVWA y proporcionarle el entorno Apache/PHP/MySQL necesario.

A continuación, se presentan dos enfoques: un método “clásico” con un paquete de servidor local y un método “limpio” con Docker.

Opción 1: Instalar DVWA con un servidor local (MAMP / XAMPP / WAMP)

Este método es ideal si prefieres interactuar directamente con los directorios y archivos para comprender la estructura. Instalas un paquete de software que contiene todo lo necesario: Apache + PHP + MySQL.

En macOS, MAMP es una opción común. En Windows, XAMPP es la opción más común. Instalar DVWA en XAMPP sigue exactamente el mismo proceso que en MAMP o WAMP: Apache activo, MySQL activo y la carpeta dvwa dentro de htdocs. En Linux, puedes configurar tu propio stack, pero para un principiante, un paquete es más rápido.

Una vez instalado el paquete, inicia los servicios de Apache y MySQL desde su panel de control.

Luego, descarga DVWA desde GitHub y coloca el directorio en tu carpeta web local. En MAMP y XAMPP, este directorio suele llamarse htdocs.

Preparar el entorno (MAMP)

1. Inicia MAMP.
2. Verifica que los servidores Apache y MySQL estén activos (indicadores en verde).

Descargar y ubicar DVWA

1. Para descargar DVWA, utiliza siempre el repositorio oficial de DVWA en GitHub.

2. Descomprime el archivo y renombra la carpeta a dvwa.
3. Mueve esta carpeta al directorio raíz web de MAMP (htdocs).
4. En PhpMyAdmin, crea una nueva base de datos llamada dvwa.
5. Copia config/config.inc.php.dist a config/config.inc.php y configúralo según tu entorno.
6. Abre el archivo config.inc.php con un editor de texto (Notepad++, VS Code, TextEdit). Modifica las siguientes líneas para que coincidan con las credenciales por defecto de MAMP:

$_DVWA[ 'db_server' ]   = getenv('DB_SERVER') ?: 'localhost';
$_DVWA[ 'db_database' ] = getenv('DB_DATABASE') ?: 'dvwa';
$_DVWA[ 'db_user' ]     = getenv('DB_USER') ?: 'root';
$_DVWA[ 'db_password' ] = getenv('DB_PASSWORD') ?: 'root';
$_DVWA[ 'db_port']      = getenv('DB_PORT') ?: '3306';

DVWA tiene una página de configuración accesible desde el navegador. Al acceder, la aplicación te indicará si falta algún requisito: permisos, base de datos inexistente, parámetros incorrectos, etc. Esto es normal y forma parte del proceso.

A continuación, haz clic en el botón que inicializa la base de datos. DVWA creará sus tablas. Con esto, ya puedes iniciar sesión.

Las credenciales por defecto son generalmente admin / password.

En la página de configuración, haz clic en Create / Reset database. ¡La instalación está completa!

Una vez conectado, explora el menú. Verás varios módulos y una sección fundamental: el ajuste del nivel de seguridad.

Opción 2: Instalar DVWA con Docker (Método Limpio)

El uso de Docker es a menudo más “limpio” porque todo el entorno está aislado. No afecta a tu instalación local de PHP. DVWA se ejecuta en su propio contenedor. Al finalizar, puedes eliminar todo el entorno fácilmente.

El principio es simple: ejecutas DVWA a través de un contenedor que ya incluye todas las dependencias necesarias. Necesitarás instalar Docker Desktop. Una vez instalado, puedes lanzar DVWA utilizando una imagen existente.

Aquí tienes un ejemplo mínimo y muy común:

git clone https://github.com/digininja/DVWA.git  
cd DVWA  
docker compose up -d  

Este comando utiliza la imagen vulnerables/web-dvwa en Docker Hub, una de las más populares para este propósito.

A continuación, abre tu navegador y accede a: http://localhost:4280 (o el puerto que tengas en tu docker-compose.yml).

Si todo funciona correctamente, verás la interfaz de DVWA. Dependiendo de la imagen de Docker utilizada, es posible que debas inicializar la base de datos a través de la interfaz web, como en el método clásico.

La ventaja de Docker es que evitas problemas comunes como “mi versión local de PHP no es compatible” o “mi servidor Apache no se inicia”.

Configuración de DVWA: modos y ajustes clave

DVWA ofrece varios ajustes, pero uno es central: el nivel de seguridad.

Los niveles de seguridad de DVWA

En DVWA, puedes cambiar la dificultad. Este ajuste no es meramente estético; modifica el comportamiento del código y sus mecanismos de protección.

Generalmente encontrarás los siguientes niveles:

• Low: Protección nula o casi nula. Es el nivel ideal para comprender el funcionamiento de una vulnerabilidad. Todo está “abierto”, permitiendo observar el impacto de forma inmediata.
• Medium: Se introducen algunas protecciones, como filtrados parciales o verificaciones básicas. Es un nivel muy interesante porque se asemeja a escenarios reales: “se intentó proteger, pero de forma incompleta”.
• High: La protección es más robusta y las técnicas simples ya no funcionan. Requiere un enfoque de análisis más avanzado.
• Impossible: Teóricamente, la vulnerabilidad está corregida de forma adecuada. Sirve como ejemplo de buenas prácticas de codificación.

Cuando inicies, mantente en el nivel Low. En este nivel, el desarrollador no ha implementado ninguna protección.

El código está escrito de la forma más básica posible, lo que te permite observar con exactitud el funcionamiento técnico de una vulnerabilidad. A medida que avances, aumentarás el nivel de dificultad. El nivel Impossible es particularmente interesante, ya que muestra el código tal y como debería escribirse para estar completamente securizado.

El objetivo no es completar el ejercicio en dos minutos, sino comparar los códigos fuente. Para cada vulnerabilidad, dispones de un botón View Source en la parte inferior derecha de la página. Este es tu material de estudio. Compara el código del nivel bajo con el del nivel alto. Es al observar la diferencia entre un script vulnerable y un script robusto como desarrollarás tu intuición de hacker ético.

Opciones de PHP a supervisar

Dependiendo de tu instalación, DVWA podría indicar que faltan ciertas extensioniones de PHP, como GD (para imágenes) o configuraciones de sesión específicas.

La página de configuración de DVWA suele mostrar un estado “OK / missing” para cada requisito. No te alarmes. Simplemente toma el tiempo necesario para corregir los elementos que bloquean la instalación.

Herramientas necesarias para utilizar DVWA

DVWA puede utilizarse únicamente con un navegador. Sin embargo, para un aprendizaje profundo, necesitarás herramientas adicionales.

Existen herramientas “visuales” y herramientas de “terminal”.

Entre las herramientas visuales, el inspector del navegador es suficiente para empezar. Permite ver el código HTML, probar parámetros y observar las peticiones de red.

A continuación, está Burp Suite, que funciona como un proxy. El principio es simple: diriges tu tráfico web a través de Burp, lo que te permite observar y modificar las peticiones HTTP. Es una herramienta muy formativa. Si quieres saber más sobre ella, aquí tienes una guía completa.

En cuanto al terminal, a menudo necesitarás curl, una herramienta sencilla para enviar peticiones HTTP y realizar pruebas rápidas.

Finalmente, para ciertos ejercicios, existen herramientas como sqlmap, pero se recomienda no utilizarlas en las fases iniciales del aprendizaje. La razón es que sqlmap automatiza tanto la detección como la explotación, impidiendo la comprensión del mecanismo subyacente. El objetivo inicial no es aprender a usar una herramienta, sino a comprender el fallo.

Metodología de entrenamiento eficaz con DVWA

Antes de presentar ejemplos, es importante establecer una metodología simple.

Al analizar una vulnerabilidad, siempre debes responder a tres preguntas:

1. ¿Qué espera recibir la aplicación?
2. ¿Qué datos le estoy proporcionando?
3. ¿Cómo procesa realmente esos datos?

Mantener estas tres preguntas en mente acelera el progreso.

Una regla aún más simple: realiza las pruebas de forma incremental. No busques la “explotación definitiva” desde el primer minuto. A menudo, una vulnerabilidad se descubre con una prueba básica.

Ejemplo 1: Identificando una Vulnerabilidad XSS en DVWA

El XSS (Cross-Site Scripting) ocurre cuando una aplicación muestra datos de un usuario sin sanearlos, y dichos datos se convierten en código ejecutable en el navegador.

En DVWA, generalmente encontrarás un módulo de XSS Reflected o Stored.

• Reflected (reflejado) significa que el contenido se devuelve inmediatamente en la respuesta del servidor.
• Stored (almacenado) significa que el contenido se guarda y se muestra posteriormente a otros usuarios.

Para empezar, el XSS reflejado es ideal. Accede al módulo XSS (Reflected). Este es el ejercicio más típico de DVWA XSS para principiantes. Verás un campo de texto donde la aplicación solicita un nombre o un valor.

Introduce un valor normal, como “Juan”, y observa que se muestra en la respuesta.

A continuación, prueba con un carácter que suele causar problemas: el apóstrofo (‘). Si el apóstrofo rompe la visualización o provoca un comportamiento anómalo, ya tienes un indicador.

Luego, comprueba si el HTML es interpretado. Por ejemplo, introduce una etiqueta simple como <b>test</b>. Si la aplicación la muestra tal cual, significa que está escapando el HTML. Si la interpreta (mostrando “test” en negrita), entonces estás ante una posible vulnerabilidad.

En un entorno de entrenamiento, el objetivo es comprender que, si la aplicación muestra contenido sin escapar, potencialmente puede ejecutar JavaScript inyectado.

La herramienta principal aquí es tu navegador. Observas, revisas el código fuente y analizas lo que se renderiza.

Si deseas probar rápidamente desde el terminal, puedes enviar una petición con curl. Aquí un ejemplo conceptual:

curl "http://localhost:8080/vulnerabilities/xss_r/?name=test"

La idea no es encontrar un “comando mágico”, sino entender que un parámetro de URL puede transportar datos, y que esos datos pueden ser reflejados en la página.

Una vez que comprendes el mecanismo, entiendes la importancia de funciones como htmlspecialchars en PHP. Te das cuenta de que no es una “opción”, sino un requisito de seguridad fundamental.

Ejemplo 2: Identificando una Inyección SQL en DVWA

La inyección SQL ocurre cuando una aplicación construye una consulta SQL mezclando la sintaxis SQL con entradas de usuario no validadas. Si quieres aprender más sobre Inyección SQL en la Web Security Academy, te recomiendo sus laboratorios.

En DVWA, el módulo de SQL Injection es muy claro. Hay un campo que solicita un identificador, y la aplicación muestra información asociada desde la base de datos.

1. Introduces 1 y ves un usuario.
2. Introduces 2 y ves otro usuario.

Con esto, ya comprendes que el campo se utiliza para construir una consulta. A continuación, pruebas con una entrada que pueda provocar un error de SQL, como un apóstrofo (‘).

Si DVWA está en modo Low, es muy probable que aparezca un error de SQL. En ese momento, tienes una señal clara: estás inyectando algo que rompe la sintaxis de la consulta.

De nuevo, puedes usar el navegador, pero también curl.

Por ejemplo:

curl "http://localhost:8080/vulnerabilities/sqli/?id=1&Submit=Submit"

El objetivo aquí no es “hackear el sistema”, sino comprender que si la aplicación inserta el valor id en una consulta del tipo:

SELECT * FROM users WHERE id = 'VALOR';

entonces, si el valor no está controlado, puede modificar la lógica de la consulta.

Cuando asimilas esto, comprendes por qué las consultas preparadas (PDO con bindParam) son indispensables.

Muchas vulnerabilidades no son difíciles de explotar. Simplemente existen porque alguien programó con prisa o porque un sitio creció sin un mantenimiento de seguridad adecuado.

DVWA te coloca exactamente en esa situación, pero sin causar daños reales.

Ejercicios de Hacking Ético Prácticos con DVWA

Ahora, pasemos a la práctica. Aquí tienes cinco ejercicios concretos que puedes realizar con DVWA, en un orden lógico y progresivo. Recuerda que estos son ejercicios de hacking ético diseñados para aprender, no para atacar sistemas reales.

Ejercicio 1: El arte de la inyección SQL

Objetivo: Comprender cómo un formulario de inicio de sesión puede ser eludido si está mal programado.

Para comprender adecuadamente el uso de DVWA, nada es más efectivo que la práctica sobre una de las vulnerabilidades más conocidas de la web: la inyección SQL. Imagina que la base de datos es una caja fuerte y el formulario en pantalla es la cerradura. Normalmente, debes usar la llave correcta para acceder. La inyección consiste en introducir una herramienta en la cerradura para forzar a la caja fuerte a entregar todo su contenido, incluso lo que no te corresponde.

Dirígete a la pestaña SQL Injection.

Observarás un campo que solicita un ID de usuario. Si introduces 1, el sistema responde correctamente con el nombre del administrador. Este es el comportamiento esperado. Pero ¿qué ocurre si envías un comando que el servidor no anticipa? Para probar la vulnerabilidad, se suele utilizar un carácter especial como la comilla simple (o apóstrofo).

Si introduces únicamente una comilla simple (') y el sitio devuelve un error que menciona MySQL o sintaxis SQL (por ejemplo, “You have an error in your SQL syntax”), significa que la vulnerabilidad está expuesta.

• Tareas:
  1. Instala DVWA y activa el nivel de seguridad “Low”.
  2. Navega a la página de inicio de sesión (SQL Injection).
  3. Analiza el comportamiento de la aplicación al introducir caracteres especiales (apóstrofo, comillas). Este módulo es ideal para practicar inyección SQL en DVWA en modo Low y Medium.
  4. Estudia los errores de SQL, si se muestran.
  5. Introduce el payload completo: ‘ OR ‘1’=’1

Procedimiento paso a paso para una extracción de datos

Pasemos ahora a una manipulación concreta. Queremos forzar al sitio a mostrarnos todos los usuarios de la base de datos, no solo aquel cuyo ID conocemos. Para ello, utilizaremos una lógica matemática implacable en el campo de entrada.

Introduce el siguiente comando en el campo ID (sin comillas adicionales al final):

' OR '1'='1

A continuación se explica el proceso que ocurre en el servidor.

• La primera comilla cierra el comando previsto por el desarrollador.
• La palabra clave OR significa “o”.
• La afirmación 1=1 es siempre verdadera.

Por lo tanto, el servidor recibe la siguiente instrucción: muestra los datos si el ID está vacío O SI 1 es igual a 1. Dado que 1 es siempre igual a 1, el servidor omite la condición inicial y entrega la lista completa de los miembros del sitio.

La consulta original (la que el desarrollador escribió en el código PHP) generalmente se ve así:

SELECT first_name, last_name FROM users WHERE user_id = '$id';

Lo que ocurre durante la inyección

Cuando introduces ‘ OR ‘1’=’1 en el campo de entrada, reemplazas la variable $id. La consulta final ejecutada por la base de datos se convierte en:

SELECT first_name, last_name FROM users WHERE user_id = '' OR '1'='1';

¿Por qué funciona?

• La primera comilla de tu entrada cierra la de la consulta original (user_id = ”).
• El OR añade una condición adicional.
• Como ‘1’=’1′ es una afirmación siempre verdadera, la condición WHERE se vuelve verdadera para cada fila de la tabla.

Resultado: El servidor ignora el ID y te devuelve la lista completa de usuarios.

¡MySQL o SQL hackeado!

Este es un momento revelador. Recuerdo a un amigo desarrollador que, durante su primer uso de DVWA, se quedó asombrado ante esta simplicidad. Me confesó que había escrito decenas de sitios de esa manera durante años, sin darse cuenta de que una simple frase en un formulario podía comprometer la confidencialidad de sus clientes. Es el “clic” conceptual que todos buscamos.

• Meta final: Lograr iniciar sesión sin conocer la contraseña. Para una guía más profunda sobre esta vulnerabilidad, puedes consultar este artículo.
• Bonus: Corregir la vulnerabilidad utilizando consultas preparadas (PDO).

Lo crucial aquí es la observación. Si la aplicación responde “usuario incorrecto”, es diferente a “contraseña incorrecta”. Esa simple diferencia ya constituye una fuga de información.

Anota tus observaciones y luego cambia al modo Medium para ver si el comportamiento cambia.

Ejercicio 2: XSS en un campo de comentarios

Objetivo: Comprender cómo el contenido generado por el usuario puede volverse peligroso.

Es un ataque que se dirige a los usuarios del sitio en lugar de al propio servidor. El objetivo es inyectar un script malicioso en una página para que se ejecute en el navegador de una víctima.

En la pestaña XSS (Reflected), verás un campo que te pide tu nombre. Escribe un nombre convencional y se mostrará en pantalla. Ahora, intenta insertar código JavaScript. Escribe precisamente la siguiente línea:

<script>alert('Pwned')</script>

Si aparece una ventana emergente con el mensaje “Pwned“, lo has conseguido. El servidor ha tomado tu código y lo ha devuelto tal cual al navegador, que lo ha ejecutado.

La corrección para este nivel de dificultad consiste en utilizar funciones de PHP como htmlspecialchars(). Esta función convierte los caracteres especiales en texto inofensivo. En lugar de ejecutar la etiqueta script, el navegador simplemente mostrará el texto plano en la pantalla.

• Tareas:
  1. Utiliza el módulo XSS (Reflected) de DVWA.
  2. Introduce texto normal (ej: “Juan“) y observa que se muestra correctamente.
  3. Introduce HTML simple como test para ver si se interpreta (negrita).
  4. Introduce el payload completo: <script>alert('Pwned')</script>
  5. Cambia al nivel Medium o High para ver cómo cambian las protecciones y qué payloads dejan de funcionar.
• Meta final: Desencadenar una acción visible en el navegador (ej: una alerta) a través de una inyección.
• Bonus: Aplicar la protección correcta, como se detalla en la Guía de Prevención de XSS de OWASP (Cheat Sheet).

Este es un ejercicio extremadamente importante, ya que el XSS puede afectar a cualquier tipo de sitio: blogs, foros, áreas de miembros, paneles de administración. Un XSS almacenado en una zona de administrador puede ser el punto de partida de un incidente de seguridad grave. Comprender el Cross-Site Scripting es fundamental para cualquier desarrollador.

Ejercicio 3: Control de Acceso Roto (Broken Access Control / File Inclusion)

Objetivo: Probar si puedes acceder a un recurso sin tener los permisos necesarios.

DVWA incluye módulos que ilustran Broken Access Control, como File Inclusion y el acceso directo a páginas administrativas. Esta vulnerabilidad permite a un atacante forzar al servidor a leer un archivo que no debería mostrar, como el archivo de contraseñas del sistema o archivos de configuración sensibles.

Observa la URL de la página. A menudo verás algo como ?page=include.php. El ejercicio muestra principalmente un ataque de Inclusión Local de Archivos (LFI). Intenta reemplazar include.php por ../../../../etc/passwd (o más “../” según la profundidad) si estás en un sistema tipo Unix como macOS con MAMP.

(Nota: para probar Inclusión Remota de Archivos –RFI– necesitas activar manualmente allow_url_include = On en php.ini, algo que no viene por defecto en instalaciones modernas por seguridad.)

La corrección de esta vulnerabilidad se basa en una “lista blanca” (whitelist). El desarrollador debe codificar de manera que solo las páginas explícitamente autorizadas puedan ser llamadas por la URL. Si el usuario solicita cualquier otro recurso, el servidor debe devolver un error.

Incluso sin ser un experto, puedes aprender mucho: si una página debe ser privada, la autorización debe verificarse siempre en el lado del servidor.

• Tareas:
  1. Inicia sesión como un usuario normal.
  2. Intenta acceder a una URL de administrador directamente (ej: /admin.php o /vulnerabilities/exec/).
  3. Prueba cambiar parámetros como ?id=1 a ?id=2 para ver datos de otro usuario.
  4. Observa la URL y busca parámetros como ?page=include.php para probar File Inclusion.
  5. Reemplaza el valor del parámetro page por ../../../../etc/passwd (o más “../” según la profundidad del directorio) para intentar LFI.
• Meta final: Verificar si puedes acceder a recursos prohibidos simplemente escribiendo la URL.
• Bonus: Probar también con parámetros como ?id=2 para ver si puedes leer la información de otro usuario.

Ejercicio 4: Fuerza bruta y protecciones

Objetivo: Medir la fragilidad de una página de login sin mecanismos de protección.

En el módulo de brute force de DVWA, puedes analizar su comportamiento. ¿El sitio te bloquea después de X intentos? ¿Ralentiza las respuestas? ¿Registra los intentos fallidos?

Aquí te enfrentas a un formulario de inicio de sesión estándar. El objetivo es probar una multitud de combinaciones de contraseñas hasta encontrar la correcta. Se trata de un ataque de fuerza bruta.

En el modo Low, no hay límite de intentos. Puedes probar mil veces, el servidor no te bloqueará.

Para superar este ejercicio, puedes utilizar una herramienta externa como Hydra o Burp Suite, pero para empezar, simplemente prueba las combinaciones más comunes como admin / password o admin / admin.

La corrección técnica aquí no se limita a una contraseña compleja. Un buen desarrollador debe implementar un sistema de bloqueo de cuenta tras un número determinado de intentos fallidos (por ejemplo, tres) o añadir un retardo entre cada intento para que el ataque sea tan lento que resulte inviable para un humano o una máquina.

• Tareas:
  1. En DVWA, activa el nivel de seguridad “Low”.
  2. Navega al módulo Brute Force.
  3. Introduce combinaciones manuales: admin / password, admin / admin, admin / 123456 (prueba 10-20 veces).
  4. Observa la velocidad de respuesta: ¿se bloquea? ¿se ralentiza? ¿muestra mensajes de error útiles?
  5. Cambia al modo Medium o High para ver cómo cambian las protecciones (por ejemplo, si añade un retardo o bloqueo).
• Meta final: Medir cuántos intentos son posibles en un minuto sin que el servidor bloquee o ralentice el ataque.
• Bonus (conceptual): Añadir protecciones como:
  • Límite de peticiones progresivo (rate limit).
  • Un captcha después de X intentos.
  • Bloqueo temporal de IP.
  • Registros (logs) y alertas.

Rápidamente comprenderás por qué existen las buenas prácticas de rate limiting. Y también notarás que algunos sitios reales carecen de cualquier protección. Aquí puedes aprender más sobre cómo funcionan y cómo protegerte de los ataques de fuerza bruta.

Ejercicio 5: Fuga de información pasiva

Objetivo: Recopilar la máxima cantidad de información posible sin autenticarse.

Inspecciona las cabeceras HTTP, los errores del servidor, las pistas en el código fuente y los archivos accesibles. A veces, DVWA expone información deliberadamente con fines de aprendizaje.

• Inspecciona:
  • Las cabeceras HTTP (Server, X-Powered-By…).
  • El archivo robots.txt.
  • Archivos públicos involuntarios (.env, .git, copias de seguridad .zip, .sql, etc.).
  • El código fuente HTML (comentarios, claves de API visibles, endpoints internos).
• Meta final: Producir una lista de 10 datos “sensibles” recuperados sin autenticación.
• Bonus (conceptual): Fortalecer la configuración: eliminar cabeceras innecesarias, proteger directorios, denegar el acceso a archivos sensibles.

Esta es una habilidad subestimada. Muchas vulnerabilidades se descubren simplemente mediante la observación inteligente.

Ejercicio 6: La carga de archivos peligrosos

Objetivo: Comprender los riesgos de subir archivos sin validación estricta.

En muchos sitios, se puede subir una foto de perfil. Pero ¿qué ocurre si envías un script PHP en lugar de una imagen?

Prepara un pequeño archivo llamado test.php que contenga únicamente la línea <?php phpinfo(); ?>. Intenta subirlo a través del formulario de carga. Si el sitio lo acepta, puedes navegar a la dirección del archivo y ver cómo se ejecutan los datos de configuración de tu servidor. Ahora tienes el control total.

La corrección aquí es triple. Se debe verificar la extensión del archivo, comprobar su tipo MIME real e, idealmente, renombrar el archivo de forma aleatoria durante el almacenamiento para que un atacante no pueda deducir su ubicación exacta en el servidor.

• Tareas:
  1. Activa el nivel de seguridad “Low” en DVWA.
  2. Navega al módulo File Upload.
  3. Crea un archivo test.php con <?php phpinfo(); ?>.
  4. Sube el archivo a través del formulario.
  5. Abre la URL del archivo subido para ver phpinfo().
  6. Cambia al modo Medium/High y repite para ver cómo falla la subida.

• Meta final: Lograr ejecutar código PHP subido (ver la página phpinfo() en tu navegador).
• Bonus (conceptual): Añadir validación de MIME real (finfo en PHP), limitar extensiones a imágenes, almacenar fuera del web root, renombrar con UUID.

Ejercicio 7: Ejecución de comandos del sistema

Objetivo: Comprender cómo una entrada no sanitizada puede ejecutar comandos arbitrarios en el servidor.

Esta es, sin duda, una de las vulnerabilidades más peligrosas.

En la sección Command Injection, el sitio te propone probar la conectividad de una dirección IP mediante un comando “ping”. El servidor toma tu entrada y la pasa directamente a la terminal del sistema operativo.

El truco consiste en utilizar un separador de comandos como el punto y coma (;) o el doble ampersand (&&).

Introduce, por ejemplo, 127.0.0.1; whoami o 127.0.0.1 && whoami.

El servidor primero ejecutará el ping y luego el comando whoami, que muestra el nombre del usuario que ejecuta el servidor web.

Para corregir esto, nunca se debe permitir que un usuario interactúe directamente con los comandos del sistema operativo. Es imperativo sanear la entrada del usuario para eliminar todos los caracteres especiales que permiten concatenar comandos maliciosos.

• Tareas:
  1. Activa el nivel de seguridad “Low” en DVWA.
  2. Navega al módulo Command Injection.
  3. Introduce una IP normal (ej: 127.0.0.1) y observa el resultado del ping.
  4. Añade un separador y comando simple: 127.0.0.1; whoami (o && whoami).
  5. Prueba otros comandos: 127.0.0.1; ls -la (lista archivos), o 127.0.0.1; cat /etc/passwd (lee archivos sensibles).
  6. Cambia al modo Medium o High y repite para ver cómo fallan los payloads simples (filtrados o escapes).

• Meta final: Ejecutar un comando del sistema (ej: whoami, ls, cat /etc/passwd) desde la web y ver el output (salida).
• Bonus (conceptual): Implementar saneamiento estricto (lista blanca de IPs válidas, usar escapeshellarg() o escapeshellcmd() en PHP, o evitar por completo funciones como system(), exec(), passthru(), shell_exec()).

Estrategia de progresión para evitar la dispersión

DVWA es muy completo, y ese es precisamente el riesgo: la dispersión. Te recomiendo un método simple: un módulo por día.

• Día 1: Realizas XSS en modo Low. Comprendes el mecanismo.
• Día 2: Repites XSS en modo Medium. Comparas los resultados.
• Día 3: Realizas Inyección SQL en modo Low.
• Día 4: Inyección SQL en modo Medium.

Y así sucesivamente. Lo más importante: después de cada ejercicio, plantéate una pregunta desde la perspectiva de un desarrollador, no de un atacante.

“¿Cómo corrijo esta vulnerabilidad en mi propio código?”

Es en este punto donde DVWA se convierte en una herramienta poderosa. Porque en lugar de coleccionar “ataques”, construyes reflejos de seguridad.

Si solo pudieras retener una idea de este tutorial de DVWA, que sea esta: no es una puerta hacia prácticas dudosas. Es una escuela, un entorno de pruebas, un lugar donde tienes permitido ser curioso. Y en el mundo del desarrollo web, la curiosidad bien dirigida es una cualidad valiosa.

Al aprender con DVWA (Damn Vulnerable Web Application), obtienes una ventaja enorme: dejas de programar “a ciegas”. Comprendes qué puede salir mal. Y cuando comprendes el riesgo, desarrollas de manera más robusta, más seria y con verdadera confianza.

Sí, a veces te sentirás un poco perdido. Probarás algo, no funcionará, y de repente sí lo hará, y tendrás esa pequeña satisfacción de “lo he entendido”. Y eso es exactamente progresar. Paso a paso. Módulo a módulo. Sin compararte con otros. Sin presión. Simplemente, aprendiendo de verdad.