Cómo protegerse de los ataques de cross-site scripting (XSS)

Es fácil quedar convencido del peligro que representan las últimas y más destacadas amenazas en línea, pero los ciberataques de vanguardia no son necesariamente tan extendidos o persistentemente peligrosos como los antiguos. Toma, por ejemplo, el cross-site scripting (XSS): Microsoft identificó y categorizó por primera vez los ataques de XSS en 2000, pero los registros de ataques de XSS se remontan a los primeros días de Internet. El sitio web de recompensas de errores HackerOne informó en julio de 2017 que los XSS continúan siendo la vulnerabilidad más común entre los usuarios de su plataforma.

Con la amenaza del cross-site scripting poco probable de disminuir, es esencial que los usuarios de Internet y los desarrolladores web sepan qué es el XSS y cómo prevenir estos ciberataques.

¿Qué es el cross-site scripting?

El cross-site scripting es lo que ocurre cuando un atacante aprovecha una vulnerabilidad en una página web para inyectar su propio código. Ese código puede robar información de los usuarios, como credenciales, cookies de sesión y otros datos sensibles, e incluso puede vivir persistentemente en un sitio para atacar a varios usuarios.

Un ataque de XSS es único porque estas vulnerabilidades no apuntan al sitio web o aplicación web que explotan, solo son un vector de ataque. El XSS utiliza scripts que se ejecutan en la máquina del usuario, y estos scripts se llaman scripts del lado del cliente. La gran mayoría de ellos están codificados en JavaScript o HTML, aunque también hay otros lenguajes que se pueden utilizar para los scripts del lado del cliente.

Los ataques de XSS se dividen en dos categorías: ataques reflejados y almacenados.

Los ataques reflejados son ataques rápidos y únicos que dependen de que los scripts del lado del servidor no eliminen correctamente las solicitudes para eliminar scripts u otros objetos incrustados.

Google lee textos en videos de YouTube sin consentimiento para rastreo de búsqueda

Un atacante que utiliza un ataque de XSS reflejado tiene que hacer que un usuario haga clic en un enlace, ya sea a través de un correo electrónico, un sitio web malicioso o en otro lugar. El enlace contiene un script malicioso que un sitio vulnerable no eliminará a través de la sanitización, por lo que el script se refleja en el sitio y se ejecuta en la computadora del usuario.

Los ataques almacenados, aunque menos comunes, son mucho más peligrosos y destructivos que los ataques reflejados. A diferencia de los ataques reflejados, que tienen una interacción mínima con un sitio web, los ataques almacenados aprovechan un sitio para que guarde el script malicioso que un atacante desea ejecutar en las computadoras objetivo.

Un ataque almacenado requiere que un sitio web almacene información de usuario en un lugar público, como una plataforma de redes sociales, un foro en línea, un sitio minorista de terceros o un sitio similar. Más específicamente, los atacantes requieren que el sitio web permita HTML no sanitizado para ser incrustado en el sitio, al cual los visitantes estarían expuestos sin saberlo simplemente al ver la página. Al igual que en un ataque reflejado, el script incrustado en el contenido infectado no sería visible, por lo que no se levantarían sospechas.

A diferencia de los ataques reflejados, que requieren que un usuario haga clic en un enlace, los ataques almacenados no requieren ninguna interacción por parte del usuario. Los ejemplos de ataques almacenados podrían incluir la incrustación de un XSS en un nombre de usuario, una publicación de blog, una descripción de producto, una publicación en un foro o cualquier otro lugar donde se permita contenido HTML generado por el usuario no sanitizado.

¿Qué tan grande es la amenaza del cross-site scripting?

Los ataques de XSS son simples: todo lo que un atacante necesita es un sitio web vulnerable y un poco de conocimiento básico de JavaScript e HTML para perturbar la vida de una persona. En otras palabras, el cross-site scripting es una gran amenaza. La mera persistencia del XSS debería ser suficiente para preocupar a cualquiera: ha sido un problema desde mediados de la década de 1990 y sigue siendo un problema importante.

Un estudio reciente de Positive Technologies encontró que casi tres cuartas partes de los sitios web probados son vulnerables a ataques de XSS. Si Positive Technologies tiene razón, eso lo convierte en la falla más comúnmente explotable en Internet.

Cómo protegerse contra los ataques de fuerza bruta y diccionario

Los ataques de XSS son capaces de robar datos sensibles de los usuarios. Uno de los blancos más sensibles del XSS son las cookies de sesión, que verifican la identidad de un usuario en un sitio web para permitir que la persona permanezca conectada mientras visita múltiples páginas en un dominio.

Si un atacante de XSS logra robar una cookie de sesión, puede duplicar la sesión activa del usuario, lo que le otorga acceso a cualquier cosa que el usuario pueda hacer en un sitio web: publicar en redes sociales, editar información personal/cuenta, cambiar contraseñas, robar información de tarjetas de crédito, realizar transferencias bancarias, comprar productos en un sitio de comercio electrónico y más.

¿Cuáles son ejemplos de ataques de cross-site scripting (XSS) importantes?

No es difícil encontrar evidencia de ataques de XSS en sitios importantes que se remontan a más de una década atrás. Los artículos de noticias están llenos de historias de ataques de XSS exitosos, algunos de los cuales incluso quedaron sin solucionar años después del incidente inicial.

• Se publicó un XSS de prueba de concepto en Facebook en 2008. Facebook solucionó la vulnerabilidad poco después de su descubrimiento, aunque se desconoce si hubo víctimas de ataques maliciosos antes de su descubrimiento público.
• La rediseño de Twitter en 2010 contenía una vulnerabilidad de XSS a la que Sarah Brown, la esposa del ex primer ministro británico Gordon Brown, cayó y compartió inconscientemente con sus más de 1,000,000 de seguidores. La explotación no requería ni siquiera hacer clic, simplemente pasar el mouse por encima, para redirigir a los usuarios a un sitio web pornográfico.
• Los usuarios de eBay han lidiado con la posibilidad de scripts XSS incrustados en las listas de productos durante años, y a principios de 2017, el problema aún no se había solucionado. En este caso, los vendedores maliciosos agregaban scripts a las listas de productos legítimas para redirigir a los usuarios a una página de inicio de sesión falsificada que robaba credenciales antes de redirigir a los usuarios de vuelta a una página de eBay legítima.
• Casi 400,000 reservas de British Airways fueron comprometidas por XSS que apuntó al sistema de pago de la aerolínea en su sitio web y en su aplicación móvil. Potencialmente, todas esas transacciones tuvieron sus detalles de tarjetas de crédito y débito robados.
• El gusano Samy que afectó a MySpace en 2005 agregó una línea sobre el desarrollador del gusano en el perfil de todos diciendo que era el héroe de la víctima. Independientemente de su naturaleza benigna, el gusano Samy utilizó XSS para infectar a más de un millón de usuarios de MySpace en menos de 20 horas, convirtiéndose en el gusano de propagación más rápida en la historia de Internet.
• Yahoo enfrentó muchos problemas de seguridad en los últimos días de su supremacía en el correo electrónico, uno de los cuales fue un ataque de phishing de XSS en 2013 que resultó en que las víctimas tuvieran sus cuentas robadas.

Estos ejemplos son, desafortunadamente, solo algunos de los principales ataques de cross-site scripting que se han publicitado. Es totalmente posible, y bastante probable, que ocurran otros ataques de XSS que resulten en el robo de información personal.

¿Cómo pueden los desarrolladores proteger sus aplicaciones web contra los ataques de cross-site scripting (XSS)?

Los desarrolladores web cuyos proyectos caen presa de ataques de XSS solo pueden culparse a sí mismos por dejar una vulnerabilidad abierta a la explotación.

En algunos casos, prevenir el XSS puede ser tan simple como agregar un par de etiquetas HTML a un sitio web. Si bien no siempre es tan simple, una práctica llamada encoding (codificación) es un buen punto de partida.

Cazando ciberdelincuentes: Guía imprescindible para profesionales de negocios

La codificación, en esencia, elimina todo el código de entrada del usuario y obliga a los navegadores web a interpretar esa entrada solo como datos. Hay varias formas de codificar la entrada del usuario en el lado del servidor y/o del cliente; el resultado final es que cualquier script HTML, CSS, JavaScript o URL se elimina y se muestra simplemente como texto.

Hay casos en los que la codificación no es ideal, como cuando tu aplicación web necesita aceptar datos de entrada ricos en lugar de solo texto.

La codificación no siempre es suficiente para detener los ataques de XSS. Por ejemplo, si un atacante proporciona una entrada del usuario que vincula a un recurso externo en lugar de colocarlo directamente en un campo de entrada, a menudo pueden entregar código malicioso sin que esté sujeto a los filtros de codificación. Esto no significa que debas ignorar la codificación como medida preventiva; debe complementarse con salvaguardas adicionales como la validación.

La validación es el segundo método principal de prevención de XSS, y consiste en eliminar el código malicioso sin eliminar todo el código que podría estar presente en la entrada del usuario. La validación se realiza generalmente de dos formas: clasificación o saneamiento.

La clasificación es un método para especificar qué etiquetas HTML están permitidas y cuáles no; esto se puede hacer mediante la inclusión o exclusión de ciertos comandos. Por lo general, se considera que la inclusión es el método superior, ya que minimiza lo que se permite y elimina la posibilidad de que se omitan elementos en una lista negra.

La clasificación actúa sobre la entrada del usuario a medida que ingresa, clasificándola como aceptable o inapropiada. Si la entrada no cumple con los criterios de una lista blanca o negra, simplemente no se permite.

Las 10 vulnerabilidades de seguridad de aplicaciones más comunes en 2018

El saneamiento utiliza un motor de validación para determinar si partes específicas de la entrada de un usuario son maliciosas, y cuando es así, el sitio elige entre rechazar la entrada o sanearla de elementos ofensivos.

En los casos en los que los usuarios necesitan confiar en HTML complejo, el saneamiento de la entrada puede ser la mejor opción, ya que permitirá que se ejecute la mayor parte del código del usuario mientras se bloquea cualquier cosa que el motor considere inapropiada. Excess XSS, un sitio que describe ataques de XSS y cómo prevenirlos, advierte que los motores de saneamiento no deben depender de las listas negras para identificar entradas no válidas, ya que eso puede hacer que el saneamiento sea ineficaz. En cambio, Excess XSS recomienda el uso de bibliotecas y marcos de saneamiento para un enfoque completo y minucioso de la inclusión en una lista blanca del saneamiento.

Un tercer enfoque que está ganando terreno es la política de seguridad del contenido (CSP, por sus siglas en inglés), que evita que se ejecuten recursos (scripts, hojas de estilo, archivos, etc.) que no sean de un dominio de confianza. Dado que los scripts inyectados probablemente no sean de dominios confiables, no se les permitirá ejecutarse y se debería evitar el ataque.

El Consorcio World Wide Web (W3C) dice que no se debe considerar a CSP como un reemplazo para la validación o la codificación. En cambio, "CSP se usa mejor como defensa en profundidad. Reduce el daño que una inyección maliciosa puede causar, pero no reemplaza una validación cuidadosa de la entrada y la codificación de salida".

Otros enfoques para la prevención de XSS incluyen bloquear los scripts por completo, aumentar la seguridad de las cookies para vincularlas a direcciones IP y forzar a las cookies a utilizar el parámetro SameSite=Strict en versiones de Chrome, Opera y Firefox posteriores a noviembre de 2017.

Si no estás seguro de qué enfoque implementar, debes investigar para encontrar cuál es el mejor para tu sitio. Cuando estés en duda, nunca está de más confiar en varios métodos.

Cómo restablecer contraseñas de cuentas locales en macOS

¿Cómo pueden los usuarios de Internet protegerse contra los ataques de cross-site scripting (XSS)?

El XSS es principalmente un problema para los desarrolladores cuyos sitios son explotados para pasar scripts de un sitio a los usuarios. No hay mucho que los usuarios finales puedan hacer para protegerse contra los ataques de XSS, ya que esas vulnerabilidades dependen del código débil del sitio web para funcionar.

Eso no significa que estés sin opciones cuando se trata de la prevención de ataques de XSS; solo significa que tus opciones son limitadas. Si deseas agregar más protección entre tú y un sitio web posiblemente no confiable, sigue estos consejos.

• Nunca hagas clic en un enlace de un correo electrónico que te pida iniciar sesión en un sitio web, podría ser una solicitud de phishing o podría estar cargado con scripts de XSS que (incluso si te lleva a un sitio web legítimo) están listos para robarte. Si recibes un correo electrónico que te pide hacer clic en un enlace de inicio de sesión, siempre es mejor abrir un navegador e iniciar sesión en tu cuenta sin seguir el enlace.
• Usa una extensión del navegador que bloquee scripts, como ScriptSafe (Chrome) o NoScript (Firefox). Estas extensiones bloquean por completo la ejecución de scripts a menos que los habilites manualmente; esto debería prevenir que los ataques de XSS se ejecuten.
• Evita hacer clic en enlaces en las redes sociales si una publicación o mensaje privado parece inusual. Las cuentas secuestradas se usan a menudo para propagar malware y lanzar ataques de XSS, y evitarlos requiere estar atento de la misma manera en que evitarías un correo electrónico de phishing.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a Cómo protegerse de los ataques de cross-site scripting (XSS) , tenemos lo ultimo en tecnología 2023.