¿Qué es el Cross-Site Scripting? Cómo prevenir los ataques XSS

Cuando pensamos en ciberataques, pensamos en violaciones de datos, virus y malware, pero ¿alguna vez has oído hablar de los ataques de cross-site scripting, también conocidos como ataques XSS? Probablemente no. A pesar de que es una de las amenazas más notorias y comunes en las aplicaciones web que usamos hoy en día. Entonces, ¿qué es?

Las aplicaciones web a menudo permiten a los usuarios interactuar con ellas enviando datos a través de formularios u otros campos de entrada. Los hackers pueden explotar esta vulnerabilidad para inyectar scripts maliciosos si la aplicación no valida y sanea adecuadamente esta entrada de usuario.

Los ataques XSS representan riesgos significativos, incluyendo pérdidas financieras, violaciones de datos, sistemas comprometidos, daños a la reputación y consecuencias legales. Los desarrolladores y propietarios de sitios web deben implementar medidas de seguridad robustas y configurar herramientas como firewalls de aplicaciones web y software de gestión unificada de amenazas para prevenir vulnerabilidades XSS.

¿Cómo funciona el cross-site scripting (XSS)?

Comencemos aprendiendo sobre la política de mismo origen para entender cómo funcionan los ataques de cross-site scripting.

Política de mismo origen

La política de mismo origen es un mecanismo de seguridad incorporado en los navegadores web que previene el robo de datos. Por ejemplo, el contenido de un sitio tiene permiso para usar cookies y otros recursos en el navegador web de un usuario. Según la política de mismo origen, el contenido de cualquier URL con el mismo identificador uniforme de recursos (URI), nombre de host y número de puerto también comparte estos permisos. Si estos tres atributos difieren, el sitio necesita un permiso separado.

Cuando la política de mismo origen no se aplica estrictamente utilizando medidas de seguridad web como la validación y saneamiento de la entrada de usuario, se crean vulnerabilidades en las aplicaciones web.

Los ataques de cross-site scripting típicamente usan JavaScript, pero cualquier lenguaje de programación del lado del cliente, como PHP, lenguaje de marcado de hipertexto (HTML) y .NET, también funcionan.

La anatomía de un ataque de cross-site scripting

Pasemos por un ejemplo para entender cómo funciona un ataque XSS:

Supongamos que hay una aplicación web con una sección de comentarios donde los usuarios pueden publicar mensajes que se muestran en el sitio web. Sin embargo, la sección de comentarios de la aplicación tiene una vulnerabilidad que no valida ni sanea adecuadamente la entrada del usuario antes de mostrarla.

Un atacante identifica esto y explota la vulnerabilidad inyectando código JavaScript dañino en una de las secciones de comentarios de las páginas web. Publican un comentario con el siguiente contenido:

Ahora, en lugar de tratar el código inyectado como texto plano, la aplicación desprotegida muestra el comentario en el sitio web sin la codificación o validación adecuada. Cuando otros usuarios visitan la página web que tiene este comentario, sus navegadores interpretan el código JavaScript inyectado como parte del contenido del sitio web y lo ejecutan.

Como resultado, aparece un cuadro de alerta, mostrando el mensaje, "¡Este es un ataque de cross-site scripting (XSS) malicioso, cuidado!" 

Si eso no fuera lo suficientemente malo, las consecuencias del ataque podrían ser mucho más graves, dependiendo de las intenciones del cibercriminal. Los actores de amenazas pueden aprovechar el script ejecutado para robar información sensible, redirigir a los usuarios a sitios web de phishing, registrar pulsaciones de teclas, capturar envíos de formularios o comprometer el sistema descargando y ejecutando malware.

Ataque XSS vs. CSRF vs. inyección SQL

Es fácil confundir XSS con inyección SQL y cross-site request forgery (CSRF) porque los tres explotan vulnerabilidades de aplicaciones web. Sin embargo, son amenazas de seguridad web distintas y varían en su naturaleza y el tipo de ataques que generan.

• Los ataques XSS inyectan códigos maliciosos en un sitio web de confianza y hacen que el navegador web del usuario lo ejecute inadvertidamente.
• Cross-site request forgery engaña a un usuario autorizado utilizando técnicas de ingeniería social como el phishing para realizar solicitudes maliciosas en nombre del usuario.
• Los ataques de inyección SQL inyectan código SQL malicioso en la capa de base de datos de una aplicación web para acceder a datos que no se suponía que se mostraran.

Historia de los ataques XSS

Las vulnerabilidades XSS se remontan a los primeros días de Internet. A medida que las páginas web se volvieron más interactivas con el lanzamiento de JavaScript en 1995, los desarrolladores comenzaron a aceptar la entrada de usuario a través de formularios y otros elementos cooperativos en las páginas web.

Sin embargo, los desarrolladores no validaron y sanearon efectivamente la entrada del usuario y expusieron vulnerabilidades que los atacantes podrían – y lo hicieron – explotar. Un equipo de ingenieros de seguridad de Microsoft acuñó por primera vez el término "cross-site scripting" para estos ataques, y con el tiempo, su definición se expandió para incluir otros tipos de ataques de inyección de código.

Antes de 2005, la mayoría de los investigadores de seguridad se centraban en otras amenazas de seguridad web como ataques de desbordamiento de búfer, gusanos, botnets o virus. Eso fue hasta que el infame gusano Samy en MySpace infectó a más de un millón de usuarios en 24 horas usando un ataque XSS, demostrando su potencial escala e impacto.

Tras el devastador golpe, la comunidad de ciberseguridad hizo esfuerzos loables para abordar las vulnerabilidades XSS. Pero incluso entonces, sigue siendo una amenaza persistente para la seguridad de las aplicaciones web. Grandes sitios web como Orkut, Youtube, Yahoo Mail, eBay, Amazon, Twitter y Facebook han enfrentado ataques XSS a lo largo de los años.

3 tipos principales de ataques XSS con ejemplos

Los ataques XSS generalmente se clasifican en tres categorías principales:

• Ataques de cross-site scripting almacenados (persistentes)
• Ataques de cross-site scripting reflejados (no persistentes)
• Ataques XSS basados en el modelo de objeto del documento (DOM)

1. Ataques XSS almacenados (persistentes)

El cross-site scripting almacenado o persistente ocurre cuando un script malicioso se almacena permanentemente en el servidor de la aplicación web objetivo y se presenta a los usuarios que acceden a una página específica. Generalmente ocurre cuando la entrada del usuario no se valida y sanea adecuadamente antes de almacenarse.

El script dañino se ejecuta automáticamente cuando otros usuarios cargan la página inyectada. Dado que la carga útil es almacenada por el servidor web y luego incrustada en una página HTML proporcionada al usuario, esto se llama un ataque XSS almacenado.

El ejemplo más común de ataque XSS almacenado son los códigos HTML no saneados que se publican como mensajes en foros en línea, registros de visitantes o campos de comentarios. Cualquier usuario que haga clic en la página donde aparece el comentario se ve afectado por el ataque, sin necesidad de desplazarse hacia abajo hasta la sección de comentarios o incluso hacer clic en ella.

2. Ataques XSS reflejados (no persistentes)

Los desarrolladores de aplicaciones tienen que estar atentos a estos con más frecuencia. En un ataque XSS reflejado, un usuario proporciona una entrada a una aplicación, y luego, el ataque no persistente hace que los scripts del lado del servidor usen esos datos de inmediato. Los scripts utilizan esa información para mostrar al usuario una página web, pero la entrada no ha sido adecuadamente saneada.

Se llama un ataque de cross-site scripting reflejado porque el servidor refleja inmediatamente la carga útil maliciosa como respuesta a una solicitud HTTP del usuario desprevenido.

Por ejemplo, una aplicación web de confianza llamada mybank.com tiene una función de búsqueda. Muestra la consulta de búsqueda de los usuarios en la página de resultados sin la validación y codificación de salida adecuadas. Un atacante podría construir la siguiente URL maliciosa para explotar esta vulnerabilidad:

El atacante luego entregará esta URL de apariencia legítima a los usuarios a través de correo electrónico u otros sitios web neutrales. Pensando que es de su sitio web bancario, uno de los usuarios hace clic en el enlace creado, y el script del hacker se ejecuta, y la víctima no se da cuenta. 

3. Ataques XSS basados en DOM

Los ataques XSS basados en DOM fueron definidos por primera vez por el investigador de seguridad de aplicaciones web Amit Klein en 2005. El modelo de objeto del documento es la representación orientada a objetos de una página web que admite contenido dinámico. Los ataques XSS basados en DOM ocurren cuando los hackers aprovechan las vulnerabilidades del DOM. La página web no cambia, pero el código del lado del cliente con la carga útil corrupta en el DOM se ejecuta en el navegador del usuario.

Los ataques XSS basados en DOM ocurren completamente en el lado del cliente, en contraste con los ataques XSS almacenados y reflejados, que ocurren debido a puntos débiles en el lado del servidor.

Otros tipos de ataques XSS

Aparte de las tres categorías principales de ataques XSS mencionadas anteriormente, existen varias otras variaciones de ataques XSS que explotan vulnerabilidades específicas.

Self-XSS

El self-cross-site scripting es más un ataque de ingeniería social en el que el intruso engaña al usuario para que pegue un JavaScript malo en su propio navegador por sí mismo. Por lo general, atraen a las víctimas publicando un mensaje que dice que el usuario podrá recibir alguna recompensa copiando y ejecutando cierto código. En realidad, el código permite al atacante secuestrar la cuenta de la víctima.

Mutación XSS

La mutación XSS o mXSS es posible debido a una vulnerabilidad en la propiedad DOM llamada innerHTML y la forma en que se analiza el código HTML al entregar contenido dinámico. Los hackers inyectan códigos maliciosos especialmente diseñados que parecen seguros, pero mutan y se convierten en vectores de ataque XSS en el navegador.

XSS ciego

Una variante de los ataques XSS persistentes, los ataques de cross-site scripting ciegos resultan en cargas útiles maliciosas que se almacenan en un servidor de aplicación web solo para ser ejecutadas por el usuario del backend o el administrador de la aplicación.

7 medidas preventivas contra ataques XSS

Las vulnerabilidades continúan existiendo en muchas de nuestras aplicaciones web, pero los investigadores han propuesto múltiples soluciones XSS, desde un simple análisis estático hasta mecanismos complejos de protección en tiempo de ejecución. Aquí se discuten algunas de ellas.

1. Marcos web y bibliotecas de codificación segura

Los marcos web modernos y las bibliotecas de codificación segura proporcionan una forma estándar de desarrollar y desplegar aplicaciones web en Internet sin fallos de diseño e implementación relacionados con la seguridad. Un desarrollador podría no tener todos los recursos para implementar adecuadamente las características de seguridad al construir una aplicación desde cero. Trabajar con bibliotecas de codificación segura y herramientas de marcos web ayuda a evitar cualquier brecha de seguridad o errores en el código.

2. Validación de entrada y codificación de salida

La validación de entrada y la codificación de salida son técnicas de defensa clave contra los ataques XSS. La validación de entrada asegura que el contenido generado por el usuario esté en el formato esperado y rechaza o neutraliza cualquier dato que no coincida con los criterios.

La codificación de salida sanea cualquier carácter especial en la entrada generada por el usuario desconocido para que se interprete como texto plano. Esto confirma que el navegador web no registre la entrada del usuario como marcado o código JavaScript bajo ninguna circunstancia. Ambas técnicas previenen vulnerabilidades de seguridad que XSS puede explotar.

3. Saneamiento HTML

Un número de desarrolladores de aplicaciones web utilizan editores de lo que ves es lo que obtienes (WYSIWYG) para crear contenido de texto y video para sus páginas web en lenguaje HTML. En estos casos, se vuelve importante sanear los códigos HTML para protegerse contra ataques XSS.

El saneamiento HTML permite etiquetas HTML básicas como <b>, <i>, <u>, <em>, y <strong>. Al mismo tiempo, elimina etiquetas más avanzadas como <script>, <object>, <embed>, y <link> que pueden ser utilizadas para inyectar códigos maliciosos.

La Open Source Foundation for Application Security (OWASP), una comunidad de seguridad líder, recomienda usar DOMPurify para el saneamiento HTML.

4. Seguridad de cookies

Dado que XSS y otros ciberataques apuntan a las cookies web, es importante implementar una seguridad adecuada de cookies. Puedes hacer esto usando atributos de cookies como la bandera "secure" y "HttpOnly" para afirmar que las cookies se transmiten solo a través de una conexión segura.

5. Política de seguridad de contenido (CSP)

CSP es una capa adicional de defensa para los propietarios de sitios web contra XSS y otras amenazas cibernéticas como el clickjacking y los ataques de inyección de código. Define y restringe las fuentes de donde los navegadores web pueden cargar contenido, como scripts, hojas de estilo o imágenes, y las URL de donde se puede cargar. CSP detiene la ejecución de códigos maliciosos especificando fuentes confiables y bloqueando o limitando el contenido.

6. Pruebas de seguridad

Las pruebas de seguridad regulares, incluyendo el escaneo de vulnerabilidades y pruebas de penetración, clasifican y abordan las vulnerabilidades XSS. Las revisiones de código manuales, escáneres de vulnerabilidades, y herramientas de pruebas de software con automatización pueden ser parte de tu rutina para detectar debilidades potenciales y medir la efectividad de las técnicas preventivas contra XSS.

7. Firewalls de aplicaciones web (WAF)

Los WAF son el software de ciberseguridad más común para proteger aplicaciones web contra XSS e inyecciones SQL. Monitorean y filtran el tráfico entrante y emplean análisis para bloquear cualquier solicitud anormal a la aplicación y negar la inyección de scripts maliciosos.

El software de seguridad como las plataformas de gestión unificada de amenazas (UTM) también protege eficazmente contra los ataques XSS al integrar múltiples características de seguridad.

Cross-site scripting: Preguntas frecuentes (FAQs)

1. ¿Qué es el cross-site scripting?

Los ataques de cross-site scripting (XSS) son vulnerabilidades de seguridad de aplicaciones web que permiten a los hackers inyectar scripts maliciosos en páginas web. Estos scripts roban información sensible, manipulan interacciones de usuario o entregan malware.

2. ¿Qué lenguaje se utiliza en los ataques de cross-site scripting?

Cualquier lenguaje de programación del lado del cliente como Javascript, HTML, VBScript o Flash puede ser utilizado para escribir códigos maliciosos en ataques de cross-site scripting. Pero Javascript y HTML son los más comúnmente utilizados para ataques XSS.

3. ¿Cuáles son los tres tipos de ataques de cross-site scripting?

Los tres tipos principales de XSS son XSS almacenado, XSS reflejado y XSS basado en DOM. 

4. ¿Cuál es la diferencia entre XSS y CSRF?

XSS inyecta y ejecuta scripts maliciosos en el navegador de un usuario, mientras que CSRF se centra en explotar la confianza depositada en la sesión autenticada de un usuario para realizar acciones no autorizadas en su nombre.

5. ¿Cuál es la diferencia entre XSS y la inyección SQL?

Los ataques XSS apuntan a los usuarios del sitio web. La inyección SQL se centra en los mecanismos de almacenamiento y recuperación de datos del sitio web.

Defendiendo el reino digital

Hoy en día, el mundo funciona con aplicaciones. El cross-site scripting sigue siendo una vulnerabilidad de seguridad peligrosa. Expone a los usuarios web a acceso remoto, robo de datos y pérdidas monetarias. Pero con la conciencia adecuada y medidas preventivas, su impacto puede ser mitigado si puedes ayudar a escribir un web más seguro si implementas las medidas preventivas compartidas aquí.

¿Quieres escribir códigos más seguros? Aprende sobre software de entrenamiento de código seguro y cómo ayuda a desarrolladores y programadores.