En el mundo del pentesting, uno de los errores más comunes en etapas iniciales es subestimar el impacto de una vulnerabilidad XSS.

Muchos estudiantes asocian XSS únicamente con un pop-up en pantalla.
Sin embargo, cuando se analiza correctamente su potencial ofensivo, se entiende que puede convertirse en un vector crítico de compromiso completo.

Este artículo está pensado para los alumnos del grupo de seguridad ofensiva de Malbec Defense, con el objetivo de comprender:

• Qué es realmente XSS
• Cómo se explota en escenarios reales
• Cómo se encadena con otras vulnerabilidades
• Qué impacto puede tener a nivel técnico y organizacional

📌 ¿Qué es Cross-Site Scripting?

Cross-Site Scripting (XSS) es una vulnerabilidad de inyección de código del lado del cliente.

Se produce cuando una aplicación web permite que datos ingresados por un usuario sean renderizados en el navegador de otro usuario sin validación ni sanitización adecuada.

El navegador interpreta ese contenido como legítimo y ejecuta el script.

Clasificación principal

• Stored XSS (Persistente) → el payload se almacena en el servidor (ej. comentarios).
• Reflected XSS → el payload viaja en la solicitud y se refleja en la respuesta.
• DOM-Based XSS → la manipulación ocurre en el DOM del navegador.

👁️ Blind XSS: el ataque diferido

Blind XSS ocurre cuando:

• El atacante no ve la ejecución inmediata del payload.
• El código se ejecuta en otro contexto (por ejemplo, cuando un administrador revisa comentarios).
• El atacante debe esperar interacción futura.

En auditorías reales, el Blind XSS es especialmente relevante en:

• Paneles administrativos
• Sistemas de ticketing
• Plataformas de soporte
• Formularios internos

Impacto: la ejecución ocurre en un contexto privilegiado.

📂 XSS a través de carga de archivos

Un escenario clásico en laboratorios:

1. La aplicación permite subir archivos.
2. El nombre del archivo se refleja en pantalla.
3. No existe sanitización del input.
4. El nombre puede contener código ejecutable.

Aquí el problema no es la carga del archivo en sí, sino la falta de validación en la salida.

⚠️ Principio clave para pentesters:
La vulnerabilidad suele estar en el renderizado, no en el upload.

🖥️ Escalada a Reverse Shell

Un error conceptual frecuente es pensar que XSS afecta únicamente al navegador.

En escenarios mal configurados, puede ser un puente hacia:

• Carga de payloads adicionales
• Descarga de archivos maliciosos
• Conexiones reversas
• Compromiso del servidor

En entornos de laboratorio (como bWAPP o PortSwigger), se demuestra cómo:

1. Se inyecta código vía XSS.
2. Se aprovecha una funcionalidad vulnerable (como upload).
3. Se ejecuta código remoto.
4. Se obtiene acceso shell.

Esto muestra cómo XSS puede ser parte de una cadena de explotación.

¿Sigue siendo inofensivo? Veamos cómo podría hacerse en un entorno de laboratorio.

¿Sigue siendo inofensivo? Veamos cómo podría hacerse en un entorno de laboratorio.

Antes de ejecutar cualquier payload, el pentester debe preguntarse:
¿Qué tipo de aplicación es? ¿Es pública? ¿Interna? ¿Administrativa?
El impacto de un XSS cambia radicalmente si se ejecuta en:
- Un blog público.
- Un panel de administración.
- Un sistema financiero.
- Una intranet corporativa.

El verdadero objetivo no es “obtener shell”, sino evaluar el riesgo real para la organización.

1️⃣ Preparación del payload

Abrimos la terminal de Kali Linux y creamos un payload PHP de reverse shell copiándolo desde el directorio de webshells:

2️⃣ Configuración del payload

Para capturar la conexión remota, se debe modificar el parámetro $ip con la dirección IP de la máquina atacante (Kali).

Ejemplo dentro del archivo:

Aquí se define:

• IP del atacante
• Puerto de escucha
• Comandos iniciales que ejecutará la shell

3️⃣ Subida del archivo en la aplicación vulnerable

Volvemos a la aplicación vulnerable y seleccionamos la opción:

“Unrestricted File Upload”

Luego subimos el archivo ReverseXSS.php.

⚠ Importante:
Copiar la URL del archivo subido (clic derecho en el botón Upload → “Copy Link Location”).

4️⃣Inyección del payload

En la sección de comentarios, debemos escribir nuestro payload JavaScript utilizando la URL del archivo subido (por ejemplo, el ReverseXSS.php).

Ejemplo conceptual:

Este script redirige al navegador hacia el archivo previamente cargado.

5️⃣Preparación del listener

⚠ Antes de presionar el botón “Submit”, debemos iniciar el listener en nuestra máquina atacante.

En la terminal:

Esto abre un puerto a la espera de una conexión entrante.

6️⃣Ejecución y obtención de acceso

Una vez que el payload se ejecuta y el archivo es invocado, si todo está correctamente configurado, se establece la conexión reversa.

En el laboratorio, se observa acceso al servidor web objetivo, ejecutando comandos como:

• uname -a
• id
• whoami

Esto confirma que se ha obtenido una shell interactiva en el servidor.

🧠 Reflexión Técnica Importante

Podrías preguntarte:

¿Por qué hacer todo este recorrido si ya existe una vulnerabilidad de carga de archivos?

La respuesta es estratégica.

Si se accede directamente al archivo subido:

• La IP del atacante queda expuesta.
• Puede ser bloqueada por firewall.
• Puede no estar en lista blanca.
• Se genera un evento sospechoso inmediato.

En cambio, usando XSS como intermediario:

✔ La conexión se origina desde un usuario autorizado.
✔ Se reduce la exposición directa del atacante.
✔ Se simula tráfico legítimo.
✔ Se demuestra encadenamiento de vulnerabilidades.

Este laboratorio no trata sobre subir una webshell.

Demuestra:

• Cómo XSS puede convertirse en vector de pivoting.
• Cómo una vulnerabilidad del lado cliente puede activar una del lado servidor.
• Cómo la cadena de explotación es más importante que la vulnerabilidad individual.
• Cómo el contexto y el privilegio determinan el impacto real.

🔁 XSS + CSRF: manipulación silenciosa de cuentas

Si una aplicación presenta:

• Vulnerabilidad XSS
• Falta de protección CSRF

El atacante puede:

• Cambiar contraseñas
• Modificar email
• Alterar configuraciones
• Ejecutar acciones en nombre del usuario

El navegador interpreta la solicitud como legítima porque utiliza la sesión autenticada de la víctima.

Este encadenamiento es crítico en auditorías de aplicaciones legacy.

🔑 Captura de Hash NTLM mediante XSS

En entornos Windows integrados con autenticación NTLM:

Un XSS puede forzar solicitudes hacia recursos controlados por el atacante.

Resultado:

• Captura de hash NTLM
• Posible crackeo offline
• Movimiento lateral en red corporativa

Este escenario demuestra que XSS puede tener impacto más allá del navegador.

🍪 Secuestro de sesión (Session Hijacking)

Uno de los impactos más directos:

1. Se inyecta código que exfiltra document.cookie.
2. Se captura el Session ID.
3. Se reutiliza en otro navegador.
4. Se obtiene acceso como usuario autenticado.

Si la cookie no está configurada como:

• HttpOnly
• Secure
• SameSite

El riesgo es inmediato.

En un entorno empresarial, esto puede implicar:

• Acceso a datos sensibles
• Escalada de privilegios
• Acceso administrativo

🔓 Captura de credenciales

En escenarios más elaborados, el atacante puede:

• Inyectar un formulario falso
• Interceptar credenciales
• Enviarlas a un servidor externo

Este método convierte el XSS en un phishing interno dentro del propio dominio confiable.

Impacto psicológico:
El usuario confía en el dominio legítimo.

💣 XSS + SQL Injection

En entornos inseguros, puede ocurrir:

1. Existencia de SQL Injection.
2. Uso de UNION SELECT.
3. Inyección de código en formato hexadecimal.
4. Ejecución vía navegador.
5. Visualización del dump completo de base de datos.

Este tipo de cadena muestra el verdadero riesgo de no aplicar defensa en profundidad.

🛡️ Medidas defensivas clave

Desde el punto de vista Blue Team:

• Validación y sanitización estricta de inputs
• Escape correcto de salida
• Implementación de CSP (Content Security Policy)
• Cookies con flags HttpOnly y SameSite
• Protección CSRF
• Revisión de uploads
• Principio de privilegios mínimos

🧠 Conclusión

Cross-Site Scripting no es un simple alert(1).

Es una vulnerabilidad crítica que puede permitir:

• Robo de sesión
• Robo de credenciales
• Captura de hashes
• Manipulación de cuentas
• Ejecución remota
• Exfiltración de base de datos

El verdadero aprendizaje no está en ejecutar el payload, sino en entender:

• El contexto
• El impacto
• El encadenamiento
• El riesgo organizacional

🔐 Formación en Seguridad Ofensiva

En Malbec Defense formamos profesionales que entienden la seguridad desde una perspectiva técnica, estratégica y responsable.

Si sos estudiante o profesional IT y querés profundizar en:

• Pentesting web
• Análisis de vulnerabilidades
• Red Team
• Seguridad aplicada

¿Querés acceder a los laboratorios internos de Malbec Defense?
Sumate a nuestra formación en seguridad ofensiva.

🧪 Debate Técnico para la Comunidad

Si un XSS se ejecuta en:

1️⃣ Un usuario sin privilegios
2️⃣ Un usuario administrativo
3️⃣ Un CISO autenticado en la intranet corporativa

¿El impacto es el mismo?

Analizá:

• Superficie de ataque
• Privilegios heredados
• Movimiento lateral posible
• Impacto organizacional y legal

💬 La discusión está abierta para miembros de Malbec Defense.