# Cross-site scripting

> Meter código en un sitio web para que se ejecute en los navegadores de otros visitantes.

- Nivel: Intermedio
- Temas: Seguridad
- URL: https://tidbit.legios.com.ar/es/cross-site-scripting/
- En inglés: [Cross-site scripting](https://tidbit.legios.com.ar/cross-site-scripting/)

Los sitios web muestran todo el tiempo texto que escribió otra persona: comentarios, reseñas, nombres de usuario, lo que buscaste. El **cross-site scripting**, que casi todos llaman **XSS**, ocurre cuando un sitio muestra ese texto sin asegurarse de que siga siendo texto. Si un atacante escribe un comentario con un poco de JavaScript disfrazado dentro de HTML, y el sitio lo pega en la página tal cual, el navegador web de cada visitante lo lee como parte de la página y lo ejecuta.

Ese código corre con la identidad del propio sitio. Puede leer lo que muestra la página, actuar como el visitante logueado (publicar, cambiar configuraciones, mandar mensajes), mostrar un cuadro de login falso o llevarse las cookies de sesión para que el atacante se quede con la cuenta. El visitante no hizo nada mal: abrió un sitio confiable. La falla está en el sitio, que dejó entrar código de afuera a sus páginas.

Hay algunas variantes. El XSS **almacenado** vive en la base de datos del sitio, como el comentario de arriba, y afecta a todos los que lo ven. El XSS **reflejado** rebota en un enlace: la parte maliciosa está en la URL y la página se la devuelve a quien hace clic. El XSS **basado en DOM** pasa entero dentro del navegador, en el propio JavaScript del sitio.

Las defensas son conocidas. Los desarrolladores **escapan** o codifican todo lo que viene de afuera antes de ponerlo en una página, así un `<` aparece como el carácter en vez de abrir una etiqueta; los frameworks modernos lo hacen solos. Una **Content Security Policy** le dice al navegador qué scripts espera realmente el sitio, y marcar las cookies de sesión como `HttpOnly` evita que los scripts las lean. La guía de OWASP cubre todo esto en detalle.

## Una analogía

Una cartelera de un club donde el encargado lee en voz alta cada nota. Si alguien pincha una que dice 'todos, denle las llaves de su casa a la persona de la puerta', un lector distraído la anuncia como si fuera oficial. Un buen lector dice 'esta nota dice…' y nunca la trata como una orden.

## Para quedarse

- El XSS mete el script de un atacante en una página confiable, que ejecutan otros visitantes.
- El script actúa con la sesión del visitante en ese sitio.
- Almacenado, reflejado y basado en DOM son las tres variantes principales.
- Escapar la salida, la Content Security Policy y las cookies HttpOnly son las defensas principales.

## Para seguir leyendo

- [Cross-site scripting (MDN)](https://developer.mozilla.org/es/docs/Glossary/Cross-site_scripting)
- [Cross-site scripting en Wikipedia](https://es.wikipedia.org/wiki/Cross-site_scripting)
- [Cross Site Scripting, OWASP (en inglés)](https://owasp.org/www-community/attacks/xss/)

## Términos relacionados

- [JavaScript](https://tidbit.legios.com.ar/es/javascript/): El lenguaje de programación que corre en las páginas web y las vuelve interactivas.
- [HTML](https://tidbit.legios.com.ar/es/html/): El formato de texto que describe qué hay en una página web: títulos, párrafos, links.
- [Navegador web](https://tidbit.legios.com.ar/es/web-browser/): La app que trae páginas web desde internet y las dibuja en tu pantalla.
- [Cookies](https://tidbit.legios.com.ar/es/cookies/): Notitas que un sitio le pide a tu navegador que guarde, para reconocerte después.
- [Base de datos](https://tidbit.legios.com.ar/es/database/): Un depósito ordenado de datos que los programas consultan y actualizan sin riesgo.
- [URL](https://tidbit.legios.com.ar/es/url/): La dirección completa de algo en la web: protocolo, sitio y ruta.
- [Framework](https://tidbit.legios.com.ar/es/framework/): Un esqueleto ya armado para una app: define la estructura y llama a tu código.