Laboratorio PoC de Bypass de Carga de Archivos + XSS Almacenado

Una aplicación web deliberadamente vulnerable que demuestra cómo un bypass de carga de archivos se encadena con XSS almacenado para crear cuentas de administrador puerta trasera, incluso cuando las protecciones CSP, CORS y CSRF están activas.

Publicación completa del blog: Blog de KurtiseBear

Este es un laboratorio educativo para formación en seguridad defensiva. No lo implementes en ningún lugar accesible públicamente.

Qué Demuestra Esto

La aplicación tiene controles de seguridad reales:

• Política de Seguridad de Contenido (CSP) que restringe las fuentes de scripts a 'self' (pero con 'unsafe-inline' y 'unsafe-eval')
• Sin encabezados CORS enviados, por lo que los navegadores bloquean las solicitudes de origen cruzado
• Tokens CSRF en todos los envíos de formularios (mensajes, cargas de archivos)
• Encabezados de seguridad estándar (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)

Un atacante con una cuenta de usuario de bajo privilegio encadena dos vulnerabilidades para evadirlas todas:

1. Bypass de carga de archivos -- El formulario de carga restringe a .pdf mediante un atributo accept del lado del cliente, pero el servidor no realiza ninguna validación del tipo de archivo. Un atacante sube un archivo .js que contiene JavaScript. El endpoint de descarga lo sirve desde el mismo origen, por lo que CSP y CORS no lo bloquean.

2. XSS almacenado a través del asunto del mensaje -- La función de mensajería almacena la entrada del usuario sin desinfección. La bandeja de entrada del administrador renderiza el asunto del mensaje como HTML sin procesar. La carga útil XSS utiliza un manejador `` para obtener el script subido y ejecutarlo con eval(). CSP lo permite porque se permiten 'unsafe-inline' y 'unsafe-eval'.

3. Falta de CSRF en el endpoint de la API -- La API de gestión de usuarios (/api/manage-user.php) no valida los tokens CSRF, aunque los endpoints de formulario sí lo hacen. La carga útil XSS llama a esta API utilizando la sesión del mismo origen del administrador. Incluso si CSRF estuviera presente, el JavaScript del mismo origen podría leer el token del DOM.

El resultado: cuando un administrador abre su bandeja de entrada, el XSS se activa, el JavaScript crea una cuenta de administrador puerta trasera usando la sesión del administrador. Cada defensa está en su lugar y funcionando. La cadena funciona porque nunca sale del origen.

Requisitos Previos

• Docker
• Docker Compose

Configuración

docker-compose up -d

Espera de 10 a 15 segundos para que MySQL se inicialice, luego visita http://localhost:8080

Credenciales

Rol	Correo Electrónico	Contraseña
Admin	[email protected]	admin
Usuario	[email protected]	user

Guía del Ataque

Paso 1: Inicia sesión como el usuario regular

Navega a http://localhost:8080 e inicia sesión con [email protected] / user.

Paso 2: Sube la carga útil

Ve a Subir Archivos. El formulario dice "Solo PDF" pero solo lo aplica del lado del cliente. Puedes:

• Usar las herramientas de desarrollo del navegador para eliminar el atributo accept=".pdf" del campo de archivo, o
• Usar curl/Burp para subir directamente (necesitarás incluir el token CSRF del formulario)

Sube el archivo payload.js proporcionado (o el tuyo propio). Toma nota del ID de archivo devuelto (ej., 1).

El archivo subido ahora se sirve desde /api/download.php?file_id=1 en el mismo origen. CSP no bloqueará las solicitudes a este endpoint porque es 'self'.

Paso 3: Elabora el mensaje XSS

Ve a Enviar Mensaje. En el campo de asunto, ingresa:

r.blob()).then(b=>b.text()).then(eval)">

(Reemplaza 1 con el ID de archivo real del paso 2.)

Pon cualquier cosa en el cuerpo. Marca prioridad si lo quieres al principio de la bandeja de entrada. Envía.

El manejador onerror funciona porque CSP permite 'unsafe-inline'. El eval() funciona porque CSP permite 'unsafe-eval'. La solicitud fetch al endpoint de descarga funciona porque es del mismo origen.

Paso 4: Espera a que el administrador revise su bandeja de entrada

Cierra sesión. Inicia sesión como [email protected] / admin. Ve a Bandeja de entrada.

El asunto del mensaje se renderiza como HTML sin procesar. La etiqueta `` falla al cargar, el manejador onerror se activa, obtiene la carga útil subida y eval() la ejecuta. La carga útil hace una solicitud POST a /api/manage-user.php usando la cookie de sesión del administrador (adjuntada automáticamente para solicitudes del mismo origen). No se necesita token CSRF porque el endpoint de la API no lo verifica.

Paso 5: Verifica la puerta trasera

Ve a Usuarios. Deberías ver un nuevo usuario: BackdoorAdmin con rol admin y correo electrónico [email protected].

Cierra sesión e inicia sesión con [email protected] / Compromised1! para confirmar.

Por Qué Fallaron Las Defensas

CSP blocks external scripts
  --> But the payload is hosted on the same origin via file upload
  --> And unsafe-inline/unsafe-eval allow the onerror handler and eval()

CORS blocks cross-origin requests
  --> But every request in the chain is same-origin

CSRF tokens protect form submissions
  --> But the API endpoint doesn't validate them
  --> And even if it did, same-origin JS can read tokens from the DOM

Session cookies have standard protections
  --> But same-origin requests carry them automatically

Medidas Defensivas

Lo que realmente rompería esta cadena:

1. Validación del tipo de archivo en el servidor -- Verifica el tipo MIME, la extensión del archivo y los bytes mágicos. No confíes en el cliente. Esto evita que el atacante aloje una carga útil en tu origen.
2. Codificación de salida -- Usa htmlspecialchars() en toda la salida controlada por el usuario. La bandeja de entrada renderiza $row['subject'] sin procesar. Esto elimina el XSS por completo.
3. CSP estricto -- Elimina 'unsafe-inline' y 'unsafe-eval'. Usa nonces o hashes para scripts en línea legítimos. Esto bloquea el manejador onerror y eval().
4. Content-Disposition: attachment -- Forza descargas en lugar de renderizado en línea para archivos subidos por el usuario. Esto evita que el navegador interprete el contenido subido.
5. CSRF en todos los endpoints que cambian estado -- Incluyendo endpoints de API, no solo formularios.
6. Controles de acceso en las cargas -- La API de descarga sirve cualquier archivo a cualquier usuario autenticado. Los archivos deberían estar limitados a su propietario.

Limpieza

docker-compose down -v

Descargo de Responsabilidad

Esta aplicación es deliberadamente vulnerable. Está diseñada únicamente para fines educativos y de formación en seguridad defensiva. No la implementes en ninguna red accesible a usuarios no confiables. No utilices estas técnicas contra sistemas sin autorización explícita por escrito.