Cross-Site Scripting (XSS) es un ataque cibernético en el que un pirata informático inserta un código malicioso en un formulario web o URL de una aplicación web. Este código malicioso, escrito en un lenguaje de secuencias de comandos como JavaScript o PHP, puede hacer cualquier cosa, desde destruir la página que intenta cargar hasta robar sus contraseñas u otras credenciales de inicio de sesión.

XSS hace uso de un aspecto importante de la Internet moderna, que es el hecho de que la mayoría de las páginas web se crean mientras se cargan las páginas, a veces mediante la ejecución de código en el propio navegador. Esto puede dificultar la prevención de tales ataques.

Compruebe también:

¿Cómo funciona un ataque XSS?

Cualquiera puede crear un sitio web que contenga código malicioso. En el caso de un ataque de secuencias de comandos entre sitios, el atacante organiza todo para que su código llegue a la computadora de la víctima cuando visita el sitio web de otra persona. De ahí viene la «cruz» del nombre. Los ataques XSS logran esto sin requerir acceso privilegiado a un servidor web para poner código de manera subrepticia. En cambio, los atacantes se aprovechan de la forma en que funcionan los sitios web modernos.

Si alguien te pidiera una explicación simple y básica de cómo funciona la web, probablemente podrías decirle algo como esto: la persona que quiere crear una página web escribe un documento HTML y lo coloca en un servidor web; Cuando el usuario quiere acceder a esta página, dirige su navegador a la dirección del servidor, el navegador descarga e interpreta el código HTML y crea una copia de la página web del usuario.

Esta descripción no es incorrecta, pero algunos aspectos están desactualizados (y existen desde hace más de diez años). En primer lugar, muchas páginas web, si no todas, son dinámicas en la actualidad, es decir, no muestran el mismo HTML estático a todos los visitantes, sino que se generan instantáneamente a partir de la información en la base de datos del servidor cuando el navegador solicita acceso. La página que el navegador recibe del servidor a menudo depende de la información enviada con la solicitud, información que a veces toma la forma de parámetros en la URL utilizada para acceder al sitio. Los sitios web no solo consisten en HTML y hojas de estilo en cascada (CSS) que describen cómo mostrar texto y gráficos, sino que también contienen código ejecutable escrito en lenguajes de secuencias de comandos, generalmente JavaScript.

En un ataque XSS, el pirata informático utiliza esta interacción entre el usuario y el sitio web para ejecutar código malicioso en la computadora del usuario. ¿pero cómo? Considere la siguiente URL:

https://www.google.com/search?q=CSO+en línea

Ingrese esto en la barra de direcciones de su navegador y verá los resultados de búsqueda de Google para «CSO Online». De hecho, la página que verá se ve exactamente igual que si hubiera ingresado «CSO Online» en la barra de búsqueda de su navegador o en la página de inicio de Google. Notarás, entre otras cosas, que esta frase aparece en varios lugares de la página, incluida la barra de búsqueda en las montañas:

¿Qué pasa si, en lugar de la frase inocente y exitosa «CSO en línea», esta URL contiene un código JavaScript malicioso como este?

https://www.google.com/search?<script>doEvil()</script>

doEvil() hace un muy mal trabajo aquí. Es posible que le preocupe que Google, en lugar de mostrar «CSO en línea» en la página que está regresando desde esta URL, integre dinámicamente el javascript incorrecto en la página que está representando, y que este script se esté ejecutando en su navegador , causando un lío . Sus preocupaciones serán infundadas, porque Google tiene una gran cantidad de talentosos profesionales de seguridad de TI entre sus empleados y ha implementado medidas correctivas de las que hablaremos un poco más adelante. Sin embargo, no todos los sitios son muy cuidadosos y esto te da una idea de cómo funcionan este tipo de ataques.

ataki xss

Los ataques XSS se dividen en varias categorías: ataques reflejados, ataques basados ​​en DOM y ataques almacenados. Así es como difieren:

• Ataques reflejos: también conocidos como ataques débiles, el código JavaScript malicioso se envía desde el navegador de la víctima a Google, luego se refleja en un formato ejecutable, nunca se almacena en los servidores de Google. Estos ataques a menudo son parte de una estafa de phishing, donde el enlace malicioso se disfraza como algo más divertido y se envía a la víctima por correo electrónico o SMS.
• Ataques basados ​​en DOM: Este es un tipo de ataque reflejo llamado Document Object Model, que es una API estándar que define cómo los navegadores crean una página web a partir de código HTML o JavaScript básico. La mayoría de los ataques DOM son similares al ataque reflejo descrito anteriormente, con la diferencia de que el código malicioso nunca se envía al servidor: en su lugar, se pasa como un parámetro a alguna función de JavaScript que se ejecuta en el propio navegador, lo que significa que los mecanismos que protegen en el lado del servidor no pueden proteger al usuario. Si está interesado en los detalles, PortSwigger tiene una descripción más detallada de cómo funcionan los ataques DOM.
• Ataques almacenados: de lo contrario, persistentes; El atacante utiliza las funciones interactivas del sitio web para guardar código malicioso en el servidor web. En un ejemplo típico, el atacante deja un comentario en una publicación de blog que contiene JavaScript malicioso. La próxima vez que alguien cargue esta página, se ejecutará el código.
• Vulnerabilidad al ataque XSS

¿Qué hace que un sitio web sea vulnerable a un ataque XSS? Esperemos que nuestra discusión hasta ahora haya proporcionado alguna orientación. Si su aplicación web toma ingenuamente la entrada del usuario, no la verifica en busca de código ejecutable malicioso y usa esos datos para representar una página o realizar otras operaciones, es vulnerable a este tipo de ataque.

Y los riesgos son grandes. El aspecto principal de la seguridad del navegador es la llamada política del mismo origen, que establece que un script que se ejecuta en una página puede acceder a los datos en la otra página solo si ambos lados tienen el mismo origen (definido como una combinación de URI, nombre de host, y número de puerto). Sin embargo, si se puede ejecutar JavaScript malicioso en el navegador mientras la víctima accede al sitio web, el navegador permitirá que JavaScript acceda a datos de otros sitios web que comparten un recurso con el sitio web vulnerable. JavaScript puede acceder a cookies y otra información de sesión patentada, lo cual es una buena receta para piratear las cuentas de Internet de las víctimas.

Cargas útiles XSS

En el lenguaje del malware, una carga útil es un código ejecutable que realiza las acciones requeridas por el atacante. En el caso de un ataque XSS, la carga útil es un código de secuencia de comandos que el atacante ejecuta para engañar al navegador de la víctima para que se ejecute.

Hay una lista enorme de plantillas de carga útil XSS en el repositorio de Payloadbox en GitHub. Si está familiarizado con JavaScript, revisarlo podría darle una idea de cómo los atacantes XSS hacen el trabajo sucio. Sin embargo, un ataque XSS va más allá de cortar y pegar la carga útil en la URL: el atacante debe comprender las funciones y vulnerabilidades específicas de la aplicación web que desea explotar para planificar el ataque. Si desea profundizar más y ver algunos ejemplos de ataques XSS, consulte el sitio web de OWASP XSS para ver en profundidad el código de secuencia de comandos que muestra un ataque XSS.

Protección y Prevención XSS

Si está creando o manteniendo una aplicación web o un sitio web interactivo, existen tres técnicas principales que debe considerar en su diseño para evitar posibles ataques de secuencias de comandos entre sitios.

• Esterilización de datos de entrada. La respuesta obvia para evitar que el código malicioso se pase como entrada y se devuelva al usuario es simplemente no aceptar el código de secuencia de comandos como entrada. Definitivamente deberías filtrar tu entrada teniendo esto en cuenta, pero es más fácil decirlo que hacerlo; Pequeños fragmentos de código ejecutable pueden colarse a través de los filtros. Una forma de lidiar con este problema es usar una lista blanca en lugar de una lista negra; por ejemplo, en lugar de intentar escribir un filtro que bloquee todo el código malicioso que se ingresa en un formulario web, debe escribir su aplicación para aceptar el datos en determinados momentos Formatos (números de teléfono, direcciones de correo electrónico, etc.) sólo cuando eso es lo que desea.
• Escapar de la salida. Esta es la solución al problema por otro lado. Si una aplicación web envía la entrada del usuario a una página web, estos datos deben filtrarse para garantizar que no se conviertan en ejecutables en esa página. Si el usuario ingresa etiquetas HTML como entrada, la aplicación debe usar caracteres anulados para que estas etiquetas aparezcan como texto en la página de resultados en lugar de integrarse con el HTML de la página misma.
• Política de seguridad de contenido estándar (CSP). CSP toma el enfoque de «lista blanca» fuera de la entrada de texto en el ámbito de las secuencias de comandos: una aplicación web solo debe ejecutar el código que el usuario ha especificado para ser seguro. Google tiene excelentes recursos para implementar CSP.

Prueba XSS

La prueba de vulnerabilidad para ataques XSS es un aspecto importante para garantizar la seguridad de una aplicación web. OWASP tiene recursos que detallan cómo se pueden probar las aplicaciones para evitar ataques DOM o secuencias de comandos inversas entre sitios. Si está buscando una hoja XSS, OWASP también tiene un documento con código de ataque XSS para usted que puede usarse para eludir algunos filtros de defensa XSS; Será de gran valor en las pruebas de penetración que puede realizar en sus propios sistemas.

XSS y CSRF

Es posible que escuche que CSRF se usa en el mismo contexto que XSS. Es la abreviatura de Cross-Site Request Forgery, un ataque, como XSS, que se dirige al navegador de un usuario. La principal diferencia es que CSRF usa una sesión autenticada para el usuario (quizás esté conectado a su cuenta bancaria) mientras que XSS no necesita una sesión autenticada para ser efectivo.

Supongamos que un usuario inició sesión en Twitter y en un banco de Internet al mismo tiempo, y hace clic en un enlace de Twitter que se ve así:

http://www.subanco.com/sendmoney,do?from=you&to=attacker&amount=5000

Dependiendo de la forma en que su banco administre los tokens de sesión y el navegador que esté utilizando, de repente pueden volverse mucho más pobres. XSS es un vector de ataque más peligroso, pero es importante defenderse contra XSS y CSRF. OWASP ha preparado una hoja informativa sobre medidas de protección contra CSRF.

Ataques XSS recientes e infames

Uno de los ataques de secuencias de comandos entre sitios más antiguos y famosos ocurrió en 2005, cuando el emprendedor usuario de MySpace Sammy Kamkar se dio cuenta de que podía ingresar un código JavaScript en su perfil que autenticaría automáticamente a cualquier persona que visitara el sitio, y también copiar ese código en los perfiles de su nuevos amigos, Gracias a eso, todos los que visiten estas páginas también serán sus amigos. (El guión se aseguró de que cada uno de los nuevos amigos de Kamkar se ubicara entre los «ocho primeros»; tenemos miedo de entender eso, tendrías que estar allí, pero créenos, importaba). En 24 horas, hizo más de un millón de amigos y obligó a MySpace a cerrar todo el sitio por un corto tiempo.

Resulta que el llamado gusano Sami es en su mayoría inofensivo. Sin embargo, otros eran más molestos:

• Ebay tuvo vulnerabilidades XSS durante años que permitieron a los piratas informáticos robar las credenciales de inicio de sesión de los usuarios

• Los atacantes XSS pudieron robar V-Bucks de los jugadores de Fortnite en 2019.

• El grupo de hackers Magecart atacó a British Airways en 2018 con un ataque XSS, robando cientos de miles de identidades de usuarios

Y las secuencias de comandos entre sitios siguen siendo una seria amenaza en la actualidad. A partir de 2021, se han encontrado vulnerabilidades XSS en la plataforma de correo electrónico Zimbra, Wordpress y la plataforma de gestión de TI de código abierto Nagios. Tenga en cuenta que, por lo general, los piratas informáticos no utilizan técnicas de ataque de forma aislada: las secuencias de comandos entre sitios son un componente de una forma compleja descubierta recientemente del ataque TLS comodín conocido como ALPACA. Para evitar amenazas peligrosas, asegúrese de cerrar las vulnerabilidades XSS.

Fuente: OSC