🛡️ Weak Session IDs en DVWA: numerando sesiones como si fueran tickets del súper

Por /

🎯 Objetivo

Aquí la idea es simple: comprobar si las sesiones son seguras…
o si están numeradas como “cliente 1, cliente 2, cliente 3…”.

Spoiler: pasa lo segundo. Y claro, así cualquiera entra.

🧪 Entorno

  • DVWA en modo LOW (modo “sin cinturón de seguridad”)
  • Endpoint: /vulnerabilities/weak_id/
  • Burp Suite + navegador

🔍 Fase 1: Observando el comportamiento

Pulsas “Generate” y aparece esto:

Set-Cookie: dvwaSession=1
Set-Cookie: dvwaSession=2
Set-Cookie: dvwaSession=3

💡 Traducción

👉 Esto no es un identificador de sesión
👉 Esto es un contador

Y cuando ves un contador… sabes que alguien lo va a recorrer.

🧠 Fase 2: Confirmando la tragedia

dvwaSession=1 → 2 → 3 → 4 → 5...
  • No hay aleatoriedad
  • No hay complejidad
  • No hay vergüenza

👉 Predecible = vulnerable

🧪 Fase 3: Interceptando con Burp

Petición capturada:

POST /vulnerabilities/weak_id/ HTTP/1.1
Cookie: dvwaSession=5; PHPSESSID=XXXX; security=low

Respuesta:

Set-Cookie: dvwaSession=6

👉 El servidor sigue contando felizmente.

🧪 Fase 4: “¿Y si pongo lo que me da la gana?”

Modificas la cookie:

Cookie: dvwaSession=50; PHPSESSID=XXXX; security=low

💥 Resultado

  • El servidor lo acepta
  • No valida nada
  • No pregunta

👉 Es como colarte en una fiesta diciendo “soy el invitado 50”.

🤖 Fase 5: Automatizando la fiesta con Intruder

Configuración:

  • Parámetro: dvwaSession
  • Payload: números
  • Rango: 1 → 100
1, 2, 3, 4, 5... 100

📊 Resultado

  • Todas las respuestas → HTTP 200
  • Mismo tamaño
  • Mismo comportamiento

👉 Da igual el número que pongas. Todo vale.

🧠 Qué significa esto

  • No hay validación de sesión
  • No hay control de integridad
  • El servidor acepta cualquier valor

👉 No estás “rompiendo” la sesión…
👉 Es que nunca estuvo bien hecha.

💥 Vulnerabilidad

Weak Session IDs + Validación inexistente

Características:

  • IDs secuenciales
  • Totalmente predecibles
  • Sin verificación en backend

🚨 Impacto real

En una aplicación de verdad, esto es bastante serio:

  • Session Hijacking
  • Suplantación de usuarios
  • Acceso sin autenticación
  • Escalada de privilegios

👉 Básicamente: no necesitas hackear… solo contar.

🛡️ Cómo hacerlo bien (de verdad)

🔑 Regla básica

👉 Las sesiones deben ser impredecibles

Medidas clave

  • Generar IDs con CSPRNG
  • Aumentar longitud y entropía
  • Validar sesiones en servidor
  • Regenerar tras login
  • Invalidar sesiones correctamente

Ejemplo decente:

session_start();

O si quieres generar algo robusto:

bin2hex(random_bytes(16));

🧠 Nota importante

👉 Si un atacante puede adivinar una sesión… ya es suya
👉 Si el servidor no valida… nunca fue tuya

🏁 Conclusión

Este fallo es de los peligrosos porque:

  • Es fácil de explotar
  • No deja ruido
  • Escala muy rápido

Y sobre todo porque demuestra algo clave:

👉 La seguridad no falla por ataques complejos
👉 Falla por decisiones simples… mal hechas

Scroll al inicio