XSS (cross-site scripting): qué es, tipos y cómo se evita

Qué es

Un XSS ocurre cuando una web incluye en una página un dato que controla el atacante y el navegador lo interpreta como código en lugar de como texto. Ese código se ejecuta con la sesión de quien visita la página: puede leer lo que ve, hacer peticiones en su nombre o cambiar el contenido.

Hay tres variantes principales:

• Reflejado: el código viaja en la propia petición (un parámetro de la URL) y la víctima tiene que abrir un enlace preparado.
• Almacenado: el código se guarda en la web (un comentario, un nombre de perfil, un fichero subido) y se ejecuta en todo el que lo vea. Suele ser el más grave.
• Basado en DOM: el fallo está en el JavaScript del cliente, que toma un dato (por ejemplo location.hash) y lo mete en la página con algo como innerHTML.

Dónde suele aparecer

• Buscadores, mensajes de error y cualquier sitio que repita lo que escribes.
• Editores de texto enriquecido, Markdown o firmas de correo con filtros caseros.
• Atributos HTML y bloques <script> donde se inserta un dato sin el escapado adecuado para ese contexto.
• Subida de ficheros SVG o HTML servidos desde el mismo dominio.
• Enlaces con esquema javascript: en campos de URL.

Cómo se busca

1. Introduce una cadena única e inofensiva (por ejemplo xsstest123"'<>) en cada campo y busca dónde aparece en la respuesta.
2. Mira en qué contexto cae: texto HTML, dentro de un atributo, dentro de JavaScript o en una URL. Cada contexto necesita una técnica distinta.
3. Comprueba qué caracteres sobreviven sin escapar. Si < y > llegan intactos al HTML, el filtro no está haciendo su trabajo.
4. Para el DOM, revisa en el código del cliente qué fuentes (location, postMessage, almacenamiento) acaban en funciones peligrosas (innerHTML, eval, document.write).

Para la prueba de concepto basta con algo visible y sin daño, como mostrar el dominio con alert(document.domain).

Cómo se evita

• Escapar siempre la salida según el contexto (HTML, atributo, JavaScript, URL). Los motores de plantillas modernos lo hacen por defecto: el problema llega cuando alguien lo desactiva.
• Si hay que admitir HTML del usuario, pasarlo por un sanitizador conocido en lugar de un filtro propio con listas negras.
• Una política de seguridad de contenido (CSP) estricta como segunda barrera.
• Cookies de sesión con HttpOnly para que el JavaScript no pueda leerlas.

Al reportarlo

Indica el tipo (reflejado, almacenado o DOM), el campo exacto y qué puede hacer un atacante en ese sitio concreto: no es lo mismo ejecutar código en una página estática que en el panel de administración.