Secuencias de comandos entre sitios
¿Qué son las secuencias de comandos entre sitios (XSS)?
Cross-site scripting (también conocido como XSS) es una vulnerabilidad de seguridad web que permite a un atacante comprometer las interacciones que los usuarios tienen con una aplicación vulnerable. Permite a un atacante eludir la misma política de origen, que está diseñada para segregar diferentes sitios web entre sí. Las vulnerabilidades de secuencias de comandos entre sitios normalmente permiten que un atacante se haga pasar por un usuario víctima, lleve a cabo cualquier acción que el usuario pueda realizar y acceda a cualquiera de los datos del usuario. Si el usuario de la víctima tiene acceso privilegiado dentro de la aplicación, entonces el atacante podría obtener control total sobre toda la funcionalidad y los datos de la aplicación.
Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!
¿Cómo funciona XSS?
Las secuencias de comandos entre sitios funcionan mediante la manipulación de un sitio web vulnerable para que devuelva JavaScript malicioso a los usuarios. Cuando el código malicioso se ejecuta dentro del navegador de la víctima, el atacante puede comprometer completamente su interacción con la aplicación.
Prueba de concepto XSS
Puede confirmar la mayoría de los tipos de vulnerabilidades XSS inyectando una carga útil que hace que su propio navegador ejecute código JavaScript arbitrario. Durante mucho tiempo ha sido una práctica común usar la alert()función para este propósito porque es corta, inofensiva y bastante difícil de pasar por alto cuando se llama con éxito. De hecho, resuelve la mayoría de nuestros laboratorios XSS invocando alert()en el navegador de una víctima simulada.
Desafortunadamente, hay un pequeño problema si usas Chrome. Desde la versión 92 en adelante (20 de julio de 2021), se impide que los iframes de origen cruzado llamen a alert(). Como estos se usan para construir algunos de los ataques XSS más avanzados, a veces necesitará usar una carga útil de PoC alternativa. En este escenario, recomendamos la print()función. Si está interesado en obtener más información sobre este cambio y por qué nos gusta print(), consulte nuestra publicación de blog sobre el tema.
Dado que la víctima simulada en nuestros laboratorios usa Chrome, modificamos los laboratorios afectados para que también se puedan resolver con print(). Hemos indicado esto en las instrucciones siempre que sea relevante.
¿Cuáles son los tipos de ataques XSS?
Hay tres tipos principales de ataques XSS. Estos son:
- XSS reflejado, donde el script malicioso proviene de la solicitud HTTP actual.
- XSS almacenado, donde el script malicioso proviene de la base de datos del sitio web.
- XSS basado en DOM, donde la vulnerabilidad existe en el código del lado del cliente en lugar del código del lado del servidor.
Secuencias de comandos entre sitios reflejadas
El XSS reflejado es la variedad más simple de secuencias de comandos entre sitios. Surge cuando una aplicación recibe datos en una solicitud HTTP y los incluye dentro de la respuesta inmediata de forma no segura.
Aquí hay un ejemplo simple de una vulnerabilidad XSS reflejada:
https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>
La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede construir fácilmente un ataque como este:
https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>
Si el usuario visita la URL construida por el atacante, la secuencia de comandos del atacante se ejecuta en el navegador del usuario, en el contexto de la sesión de ese usuario con la aplicación. En ese momento, el script puede realizar cualquier acción y recuperar cualquier dato al que el usuario tenga acceso.
Scripts entre sitios almacenados
El XSS almacenado (también conocido como XSS persistente o de segundo orden) surge cuando una aplicación recibe datos de una fuente que no es de confianza e incluye esos datos en sus respuestas HTTP posteriores de forma no segura.
Los datos en cuestión pueden enviarse a la aplicación a través de solicitudes HTTP; por ejemplo, comentarios en una publicación de blog, apodos de usuario en una sala de chat o detalles de contacto en un pedido de cliente. En otros casos, los datos pueden llegar de otras fuentes no confiables; por ejemplo, una aplicación de correo web que muestra mensajes recibidos a través de SMTP, una aplicación de marketing que muestra publicaciones en redes sociales o una aplicación de monitoreo de red que muestra paquetes de datos del tráfico de red.
Aquí hay un ejemplo simple de una vulnerabilidad XSS almacenada. Una aplicación de tablero de mensajes permite a los usuarios enviar mensajes, que se muestran a otros usuarios:
<p>Hello, this is my message!</p>
La aplicación no realiza ningún otro procesamiento de los datos, por lo que un atacante puede enviar fácilmente un mensaje que ataque a otros usuarios:
<p><script>/* Bad stuff here... */</script></p>
Scripting entre sitios basado en DOM
El XSS basado en DOM (también conocido como DOM XSS) surge cuando una aplicación contiene JavaScript del lado del cliente que procesa datos de una fuente que no es de confianza de una manera no segura, generalmente escribiendo los datos nuevamente en el DOM.
En el siguiente ejemplo, una aplicación usa algo de JavaScript para leer el valor de un campo de entrada y escribir ese valor en un elemento dentro del HTML:
var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;
Si el atacante puede controlar el valor del campo de entrada, puede construir fácilmente un valor malicioso que haga que se ejecute su propio script:
You searched for: <img src=1 onerror='/* Bad stuff here... */'>
En un caso típico, el campo de entrada se completaría con parte de la solicitud HTTP, como un parámetro de cadena de consulta de URL, lo que permitiría al atacante realizar un ataque utilizando una URL maliciosa, de la misma manera que se refleja XSS.
¿Para qué se puede utilizar XSS?
Un atacante que explota una vulnerabilidad de secuencias de comandos entre sitios normalmente puede:
- Suplantar o hacerse pasar por el usuario víctima.
- Realizar cualquier acción que el usuario sea capaz de realizar.
- Lea todos los datos a los que el usuario pueda acceder.
- Capture las credenciales de inicio de sesión del usuario.
- Realizar desfiguración virtual del sitio web.
- Inyectar funcionalidad troyana en el sitio web.
Impacto de las vulnerabilidades XSS
El impacto real de un ataque XSS generalmente depende de la naturaleza de la aplicación, su funcionalidad y datos, y el estado del usuario comprometido. Por ejemplo:
- En una aplicación de folletos, donde todos los usuarios son anónimos y toda la información es pública, el impacto suele ser mínimo.
- En una aplicación que contiene datos confidenciales, como transacciones bancarias, correos electrónicos o registros de atención médica, el impacto suele ser grave.
- Si el usuario comprometido tiene privilegios elevados dentro de la aplicación, el impacto generalmente será crítico, lo que permitirá que el atacante tome el control total de la aplicación vulnerable y comprometa a todos los usuarios y sus datos.
Cómo encontrar y probar vulnerabilidades XSS
La gran mayoría de las vulnerabilidades XSS se pueden encontrar de manera rápida y confiable utilizando el escáner de vulnerabilidades web de Burp Suite.
La prueba manual de XSS reflejado y almacenado normalmente implica enviar una entrada única simple (como una cadena alfanumérica corta) en cada punto de entrada en la aplicación, identificar cada ubicación donde la entrada enviada se devuelve en las respuestas HTTP y probar cada ubicación individualmente para determinar si la entrada adecuadamente diseñada se puede utilizar para ejecutar JavaScript arbitrario. De esta forma, puede determinar el contexto en el que se produce el XSS y seleccionar una carga útil adecuada para explotarlo.
La prueba manual de XSS basado en DOM que surge de los parámetros de URL implica un proceso similar: colocar una entrada única simple en el parámetro, usar las herramientas de desarrollo del navegador para buscar esta entrada en el DOM y probar cada ubicación para determinar si es explotable. Sin embargo, otros tipos de DOM XSS son más difíciles de detectar. Para encontrar vulnerabilidades basadas en DOM en entradas no basadas en URL (como document.cookie) o sumideros no basados en HTML (como setTimeout), no hay sustituto para revisar el código JavaScript, que puede llevar mucho tiempo. El escáner de vulnerabilidades web de Burp Suite combina el análisis estático y dinámico de JavaScript para automatizar de manera confiable la detección de vulnerabilidades basadas en DOM.
Política de seguridad de contenido
La política de seguridad de contenido ( CSP ) es un mecanismo de navegador que tiene como objetivo mitigar el impacto de las secuencias de comandos entre sitios y algunas otras vulnerabilidades. Si una aplicación que emplea CSP contiene un comportamiento similar a XSS, entonces el CSP podría obstaculizar o evitar la explotación de la vulnerabilidad. A menudo, el CSP se puede eludir para permitir la explotación de la vulnerabilidad subyacente.
Inyección de marcas colgantes
La inyección de marcado colgante es una técnica que se puede utilizar para capturar datos entre dominios en situaciones en las que no es posible una explotación completa de secuencias de comandos entre sitios, debido a filtros de entrada u otras defensas. A menudo se puede explotar para capturar información confidencial que es visible para otros usuarios, incluidos los tokens CSRF que se pueden usar para realizar acciones no autorizadas en nombre del usuario.
Descubre todo tipo de Vulnerabilidades. Con el escáner para sitios y aplicaciones web habilitado para empresas. «BURP SUITE ENTERPRISE»
Cómo prevenir ataques XSS
La prevención de secuencias de comandos entre sitios es trivial en algunos casos, pero puede ser mucho más difícil según la complejidad de la aplicación y la forma en que maneja los datos controlables por el usuario.
En general, es probable que la prevención eficaz de las vulnerabilidades XSS implique una combinación de las siguientes medidas:
- Entrada de filtro a la llegada. En el punto donde se recibe la entrada del usuario, filtre lo más estrictamente posible en función de lo que se espera o de la entrada válida.
- Codificar datos en la salida. En el punto donde los datos controlables por el usuario se emiten en las respuestas HTTP, codifique la salida para evitar que se interprete como contenido activo. Según el contexto de salida, esto puede requerir la aplicación de combinaciones de codificación HTML, URL, JavaScript y CSS.
- Use encabezados de respuesta apropiados. Para evitar XSS en las respuestas HTTP que no están destinadas a contener HTML o JavaScript, puede usar los encabezados
Content-TypeyX-Content-Type-Optionspara asegurarse de que los navegadores interpreten las respuestas de la manera que desea. - Política de seguridad de contenido. Como última línea de defensa, puede usar la Política de seguridad de contenido (CSP) para reducir la gravedad de las vulnerabilidades XSS que aún ocurren.
Preguntas frecuentes sobre secuencias de comandos entre sitios
¿Qué tan comunes son las vulnerabilidades XSS? Las vulnerabilidades XSS son muy comunes y XSS es probablemente la vulnerabilidad de seguridad web que ocurre con más frecuencia.
¿Qué tan comunes son los ataques XSS? Es difícil obtener datos confiables sobre los ataques XSS del mundo real, pero probablemente se explote con menos frecuencia que otras vulnerabilidades.
¿Cuál es la diferencia entre XSS y CSRF? XSS implica hacer que un sitio web devuelva JavaScript malicioso, mientras que CSRF implica inducir a un usuario víctima a realizar acciones que no tiene la intención de realizar.
¿Cuál es la diferencia entre XSS y la inyección SQL? XSS es una vulnerabilidad del lado del cliente que se dirige a otros usuarios de la aplicación, mientras que la inyección de SQL es una vulnerabilidad del lado del servidor que se dirige a la base de datos de la aplicación.
¿Cómo evito XSS en PHP? Filtre sus entradas con una lista blanca de caracteres permitidos y use sugerencias de tipo o conversión de tipos. Escape sus salidas con htmlentitiesy ENT_QUOTESpara contextos HTML, o escapes JavaScript Unicode para contextos JavaScript.
¿Cómo evito XSS en Java? Filtre sus entradas con una lista blanca de caracteres permitidos y use una biblioteca como Google Guava para codificar en HTML su salida para contextos HTML, o use escapes JavaScript Unicode para contextos JavaScript.
Si te ha gustado, ¡compártelo con tus amigos!
