Cross-Site Scripting: cómo funciona un ataque XSS

El Cross-Site Scripting, o XSS, es una vulnerabilidad web que permite a un atacante inyectar código, típicamente JavaScript, que se ejecuta en el navegador de otra persona dentro del contexto de un sitio de confianza. Su peligro reside en que el navegador no distingue si el código de una página lo colocó el sitio legítimo o un atacante: lo ejecuta igual, con acceso a todo lo que hay en esa página y con los permisos del sitio. Por eso un XSS exitoso puede robar la sesión del usuario, es decir las credenciales que lo mantienen conectado, y con ellas suplantarlo; puede leer o modificar el contenido de la página, incluidos datos privados; puede realizar acciones en nombre de la víctima; o puede redirigirla a un sitio de phishing. Todo esto ocurre sin que la persona note nada extraño, precisamente porque sucede dentro del sitio en el que confía. Es una de las vulnerabilidades web más extendidas y pertenece a la familia de las inyecciones, que figura entre los riesgos principales del OWASP Top 10. Comprender cómo funciona es el primer paso para prevenirlo eficazmente.

Se clasifican según dónde y cómo se inyecta el código. El XSS reflejado viaja en un enlace o formulario, dentro de un parámetro, y el sitio lo refleja de vuelta en su página de respuesta sin limpiarlo, de modo que se ejecuta en el navegador de la víctima; requiere engañar a la persona para que use un enlace preparado, y el código no queda guardado sino que solo actúa en esa respuesta puntual. El XSS almacenado, considerado el más peligroso, se produce cuando el código malicioso se envía a través de una entrada que el sitio guarda de forma permanente, como un comentario, una publicación o un campo de perfil, y a partir de ahí se ejecuta automáticamente en el navegador de todas las personas que visiten esa página, sin necesidad de engañarlas individualmente, lo que amplifica enormemente su alcance. El XSS basado en el DOM ocurre enteramente dentro del navegador, sin intervención del servidor, y surge cuando el propio código JavaScript de la página toma datos de entrada, por ejemplo de la dirección, y los inserta de forma insegura en el documento. A pesar de sus diferencias, los tres comparten la misma causa raíz y, por lo tanto, la misma familia de defensas.

La causa raíz, común a los tres tipos, es que el sitio mezcla datos con código: toma algo que escribió un usuario y lo inserta en la página sin distinguir que se trata de un dato para mostrar y no de instrucciones para ejecutar. Cuando el navegador encuentra en el HTML de la página algo que parece un script, lo ejecuta, porque no tiene forma de saber que en realidad era simplemente texto que un usuario había escrito. Esta confusión entre datos e instrucciones es exactamente la misma que origina la inyección de SQL y, en general, toda la familia de ataques de inyección. Comprender esto es fundamental porque cambia por completo el enfoque de la defensa: en lugar de intentar perseguir y bloquear cada truco de ataque conocido, tarea imposible porque siempre aparecen variantes nuevas, la solución consiste en arreglar la raíz, garantizando que los datos nunca se interpreten como código. Una vez que un sitio trata sistemáticamente los datos como datos y no como instrucciones, los tres tipos de XSS quedan cerrados de una sola vez, sin necesidad de conocer cada variante específica del ataque.

La defensa principal es la codificación de salida, que consiste en escapar los datos en el momento de mostrarlos en la página: convertir los caracteres especiales del HTML en su forma inofensiva, de manera que el navegador los muestre como texto y no los interprete como código. Así, si un usuario escribió algo que parece un script, se mostrará literalmente en la página en lugar de ejecutarse. La buena noticia es que los marcos de desarrollo web modernos realizan esta codificación de forma automática, y por eso previenen la mayoría de los ataques XSS por defecto, siempre que no se usen deliberadamente funciones que insertan HTML sin sanitizar. A esta defensa central se le suman varias capas de refuerzo. La política de seguridad de contenido, conocida como CSP, es una cabecera que indica al navegador qué scripts puede ejecutar la página, de modo que aunque una inyección se cuele, pueda impedirse que el código malicioso corra; es una defensa en profundidad que complementa, no reemplaza, a la codificación de salida. También ayudan la validación de las entradas y proteger las cookies de sesión para que el JavaScript no pueda leerlas, dificultando el robo de sesión. La clave es atacar la causa raíz tratando los datos como datos.

Los marcos de desarrollo web modernos reducen enormemente el riesgo de XSS porque, por diseño, codifican automáticamente los datos al insertarlos en la página, tratándolos como texto en lugar de como código. Esto significa que, en el uso normal, previenen la gran mayoría de los ataques XSS sin que quien desarrolla tenga que hacer nada especial, lo cual es una mejora de seguridad muy importante respecto de escribir HTML manualmente. Sin embargo, no eliminan el riesgo por completo, y es fundamental entenderlo para no caer en una falsa sensación de seguridad. Estos marcos ofrecen ciertas funciones o mecanismos que permiten insertar HTML crudo sin sanitizar, pensados para casos legítimos concretos, y si se usan con datos que provienen de usuarios sin las precauciones adecuadas, se vuelve a abrir la puerta al XSS. Del mismo modo, el XSS basado en el DOM puede surgir por cómo el propio código de la aplicación manipula datos, incluso dentro de un marco. Por lo tanto, la respuesta es que los marcos modernos son una defensa muy poderosa y hacen que lo seguro sea lo predeterminado, pero quien desarrolla debe conocer cuáles son las operaciones que saltan esa protección y usarlas con extremo cuidado, complementando siempre con defensas en profundidad como la CSP.

La guía sobre SQLi, XSS y CSRF ofrece una visión general de las tres vulnerabilidades web más emblemáticas presentándolas juntas, explicando qué es cada una, en qué se parecen y en qué se distinguen, de modo que sirve como panorama introductorio de estas amenazas relacionadas. Esta guía, en cambio, se concentra en profundidad exclusivamente en el Cross-Site Scripting, permitiéndose desarrollar con más detalle cómo funciona, los tres tipos específicos que existen, la causa raíz que comparten y, sobre todo, el conjunto completo de defensas para prevenirlo, desde la codificación de salida hasta la política de seguridad de contenido. La recomendación es usar la guía general para obtener una comprensión inicial y comparativa de las tres vulnerabilidades, y esta guía cuando se necesita entender el XSS a fondo, ya sea para prevenirlo al desarrollar o para comprenderlo en el contexto de una auditoría autorizada. Del mismo modo existe una guía dedicada específicamente a la inyección de SQL, que profundiza en la otra gran inyección con la misma lógica. Todas comparten el enfoque defensivo y educativo, orientado a proteger sistemas propios o autorizados y siempre dentro de un marco legal.