¿Qué es un «ataque de cross-site scripting» (XSS)?

La anatomía de una traición digital: qué es el XSS

Imagínate que entras en tu cafetería de confianza. El camarero te conoce, el ambiente es familiar y decides dejar una nota en el tablón de anuncios para un amigo. Sin que lo sepas, alguien ha pegado una instrucción invisible sobre tu nota: «Cualquiera que lea esto, debe entregar su billetera al encapuchado de la esquina». Tú confías en el tablón, tu amigo confía en el local, pero el mensaje ha sido alterado para manipular a quien lo consuma. En el mundo digital, esto es, a grandes rasgos, un ataque de Cross-site scripting (XSS).

El XSS no es un ataque contra el servidor en sí, como lo sería una inyección SQL que busca reventar la base de datos. Es un ataque contra el usuario, utilizando al sitio web como un cómplice involuntario. El atacante inyecta scripts maliciosos (generalmente JavaScript) en páginas web legítimas. Cuando tú, como usuario, visitas esa página, tu navegador —que confía ciegamente en el código que proviene de ese dominio— ejecuta el script malicioso. A partir de ahí, el atacante puede hacer casi cualquier cosa que tú podrías hacer: leer tus mensajes, robar tus cookies de sesión o incluso realizar compras en tu nombre.

El origen de un nombre confuso

Curiosamente, el término «Cross-site scripting» es un poco engañoso hoy en día. Fue acuñado en los primeros años de la web (alrededor de 1999-2000) por ingenieros de Microsoft. En aquel entonces, los ataques solían implicar que un sitio web malicioso cargaba un sitio legítimo en un marco (frame) e inyectaba scripts a través de esa frontera entre sitios. Aunque la técnica ha evolucionado y muchos ataques XSS actuales no requieren técnicamente cruzar entre sitios diferentes, el acrónimo XSS se quedó con nosotros para evitar confusiones con las hojas de estilo en cascada (CSS).

Tipos de ataques XSS: del descuido a la persistencia

No todos los ataques XSS se ejecutan de la misma manera. Dependiendo de cómo se introduzca y se almacene el código malicioso, podemos clasificarlos en tres categorías principales que todo administrador de seguridad debe conocer al dedillo.

1. XSS reflejado (No persistente)

Este es el tipo más común. Ocurre cuando una aplicación web recibe datos en una solicitud HTTP y los incluye en la respuesta inmediata sin la debida validación. Piensa en una página de búsqueda que muestra el texto: «Resultados para: [tu búsqueda]». Si un atacante logra que hagas clic en un enlace que contiene código en el parámetro de búsqueda, ese código se «reflejará» en la página y se ejecutará en tu navegador.

Es un ataque de un solo uso, por así decirlo. El atacante necesita que la víctima interactúe con un enlace manipulado, a menudo enviado a través de correos de phishing o mensajes directos. Es letal porque el enlace parece provenir de un sitio legítimo, lo que baja las defensas del usuario más precavido.

2. XSS almacenado (Persistente)

Aquí es donde las cosas se ponen realmente feas. En este escenario, el script malicioso se guarda permanentemente en el servidor del sitio web (en la base de datos, en un foro, en un comentario o en el perfil de un usuario). Cada vez que alguien visita la página afectada, el script se sirve automáticamente.

Imagina un foro de discusión donde un atacante publica un comentario que, en lugar de texto, contiene un script para robar cookies. Cada usuario que entre a leer ese hilo de conversación será víctima del ataque de forma silenciosa. Es extremadamente peligroso porque no requiere una acción directa del atacante hacia la víctima una vez que el código ha sido inyectado; el sitio web se convierte en un distribuidor automático de malware.

3. XSS basado en DOM

Este es el más sofisticado y difícil de detectar para los firewalls tradicionales. A diferencia de los anteriores, donde el script malicioso es parte de la respuesta HTML del servidor, en el XSS basado en DOM el ataque ocurre íntegramente en el lado del cliente. El servidor no tiene ni idea de lo que está pasando.

El script malicioso manipula el Document Object Model (DOM), que es la estructura interna que el navegador crea para representar la página. El ataque se ejecuta cuando el código JavaScript legítimo de la página toma datos de una fuente no segura (como la URL) y los escribe en la página de forma insegura. Como los datos nunca llegan al servidor en muchos casos, las herramientas de escaneo del lado del servidor suelen pasarlos por alto.

¿Por qué es tan peligroso? El impacto real

A veces se subestima el XSS como una simple molestia, pero su potencial destructivo es inmenso. No se trata solo de que aparezca una ventana de alerta diciendo «Hacked». El impacto real se mide en la pérdida de control total sobre la identidad digital del usuario.

• Secuestro de sesión: El atacante puede robar la cookie de sesión (el carnet de identidad digital que dice que ya has iniciado sesión) y usarla para entrar en tu cuenta sin necesidad de contraseña.
• Robo de datos sensibles: Puede capturar cualquier cosa que escribas en un formulario, desde tus credenciales de acceso hasta los números de tu tarjeta de crédito, antes incluso de que pulses el botón de enviar.
• Defacement y desinformación: El atacante puede cambiar el contenido visual de la página. Imagina un sitio de noticias donde un atacante inyecta una noticia falsa que parece legítima porque está bajo el dominio oficial.
• Distribución de malware: El XSS puede ser la puerta de entrada para ataques más profundos, redirigiendo al usuario a sitios que descargan troyanos o ransomware automáticamente (drive-by downloads).

Estrategias de defensa: blindando la frontera del navegador

La seguridad no es un producto, es un proceso. Para combatir el XSS, no basta con una sola herramienta; se necesita una estrategia de defensa en profundidad que abarque todo el ciclo de vida del desarrollo.

Sanitización y validación de entradas

La regla de oro es simple: nunca confíes en la entrada del usuario. Todo dato que provenga de fuera (formularios, parámetros de URL, encabezados HTTP) debe ser tratado como radioactivo. La validación consiste en asegurarse de que los datos tienen el formato esperado (por ejemplo, que una edad sea un número). La sanitización implica limpiar los datos de caracteres peligrosos como <script> o eventos onmouseover.

Codificación de salida (Output Encoding)

Esta es, quizás, la defensa más efectiva. Antes de mostrar cualquier dato en el HTML, el servidor debe codificarlo. Esto significa convertir caracteres especiales en sus equivalentes inofensivos. Por ejemplo, el carácter «<» se convierte en «&lt;». De esta manera, el navegador lo mostrará como un símbolo de «menor que» en lugar de interpretarlo como el inicio de una etiqueta de script.

Content Security Policy (CSP)

El CSP es un potente escudo moderno. Es un encabezado HTTP que le dice al navegador: «Solo confía en los scripts que provengan de estos dominios específicos». Si un atacante logra inyectar un script pero este no proviene de una fuente autorizada en la política, el navegador simplemente se negará a ejecutarlo. Es una red de seguridad vital que puede detener un ataque incluso si existe una vulnerabilidad en el código.

Preguntas Frecuentes (FAQs)