Secuencias de comandos entre sitios

La vulnerabilidad de secuencias de comandos entre sitios no persistentes (o reflejadas ) es, con mucho, el tipo más básico de vulnerabilidad web. ^{[ 9 ]} Estas vulnerabilidades aparecen cuando los datos proporcionados por un cliente web, ^{[ 10 ]} generalmente en parámetros de consulta HTTP (por ejemplo, el envío de un formulario HTML), son utilizados inmediatamente por scripts del lado del servidor para analizar y mostrar una página de resultados para ese usuario, sin sanitizar adecuadamente el contenido. ^{[ 11 ]}

Debido a que los documentos HTML tienen una estructura plana y serial que mezcla instrucciones de control, formato y el contenido real, cualquier dato no validado proporcionado por el usuario que se incluya en la página resultante sin la codificación HTML adecuada puede provocar la inyección de marcado. ^{[ 9 ] [ 11 ]} Un ejemplo clásico de un vector potencial es un motor de búsqueda de un sitio web: si se busca una cadena, esta se mostrará normalmente tal cual en la página de resultados para indicar lo que se buscó. Si esta respuesta no escapa o rechaza correctamente los caracteres de control HTML, se producirá una vulnerabilidad de secuencias de comandos entre sitios (XSS). ^{[ 12 ]}

Un ataque de redirección se suele realizar por correo electrónico o a través de un sitio web neutral. El señuelo es una URL aparentemente inofensiva que apunta a un sitio de confianza, pero que contiene el vector XSS. Si el sitio de confianza es vulnerable al vector, al hacer clic en el enlace, el navegador de la víctima puede ejecutar el script inyectado.

La vulnerabilidad XSS persistente (o almacenada ) es una variante más devastadora de una vulnerabilidad de secuencias de comandos entre sitios: ocurre cuando el servidor guarda los datos proporcionados por el atacante y luego los muestra permanentemente en páginas "normales" que otros usuarios ven durante su navegación habitual, sin el escape HTML adecuado. Un ejemplo clásico de esto son los foros en línea donde los usuarios pueden publicar mensajes con formato HTML para que otros usuarios los lean. ^{[ 11 ]}

Por ejemplo, supongamos que existe un sitio web de citas donde los miembros revisan los perfiles de otros miembros para ver si les resultan interesantes. Por motivos de privacidad, este sitio oculta el nombre real y el correo electrónico de todos. Estos datos se mantienen en secreto en el servidor. El nombre real y el correo electrónico de un miembro solo se muestran en el navegador cuando ha iniciado sesión , y no puede ver los de nadie más.

Supongamos que Mallory, una atacante, se une al sitio y quiere averiguar los nombres reales de las personas que ve en él. Para ello, escribe un script diseñado para ejecutarse desde los navegadores de otros usuarios cuando visitan su perfil . El script envía un breve mensaje a su propio servidor, que recopila esta información.

Para ello, a la pregunta "¿Describe tu primera cita ideal?", Mallory da una respuesta breve (para parecer normal), pero el texto al final de su respuesta es su script para robar nombres y correos electrónicos. Si el script está dentro de un <script>elemento, no se mostrará en la pantalla. Supongamos entonces que Bob, un miembro del sitio de citas, accede al perfil de Mallory, que contiene su respuesta a la pregunta de la primera cita. Su script se ejecuta automáticamente por el navegador y roba una copia del nombre real y el correo electrónico de Bob directamente desde su ordenador.

Las vulnerabilidades XSS persistentes pueden ser más significativas que otros tipos porque el script malicioso del atacante se ejecuta automáticamente, sin necesidad de atacar individualmente a las víctimas ni atraerlas a un sitio web de terceros. En particular, en el caso de las redes sociales, el código estaría diseñado para autopropagarse entre cuentas, creando un tipo de gusano del lado del cliente . ^{[ 13 ]}

Los métodos de inyección pueden variar enormemente; en algunos casos, el atacante ni siquiera necesita interactuar directamente con la funcionalidad web para explotar una vulnerabilidad. Cualquier dato recibido por la aplicación web (a través de correo electrónico, registros del sistema, mensajería instantánea, etc.) que pueda ser controlado por un atacante podría convertirse en un vector de inyección.

Las vulnerabilidades XSS se descubrieron originalmente en aplicaciones que procesaban todos los datos en el servidor. Los datos introducidos por el usuario (incluido un vector XSS) se enviaban al servidor y luego se devolvían al usuario como una página web. La necesidad de mejorar la experiencia del usuario impulsó la popularidad de aplicaciones cuya lógica de presentación (quizás escrita en JavaScript ) se ejecutaba principalmente en el lado del cliente y obtenía los datos del servidor bajo demanda mediante AJAX .

Dado que el código JavaScript también procesaba la entrada del usuario y la mostraba en el contenido de la página web, comenzó a aparecer una nueva subclase de ataques XSS reflejados, denominada secuencias de comandos entre sitios basadas en DOM . En un ataque XSS basado en DOM, los datos maliciosos no llegan al servidor web, sino que se reflejan mediante el código JavaScript, completamente en el lado del cliente. ^{[ 14 ]}

Un ejemplo de vulnerabilidad XSS basada en DOM es el error encontrado en 2011 en varios complementos de jQuery . ^{[ 15 ]} Las estrategias de prevención para ataques XSS basados ​​en DOM incluyen medidas muy similares a las estrategias tradicionales de prevención de XSS, pero implementadas en código JavaScript y contenidas en páginas web (es decir, validación de entrada y escape). ^{[ 16 ]} Algunos frameworks de JavaScript tienen contramedidas integradas contra este y otros tipos de ataque , por ejemplo AngularJS . ^{[ 17 ]}

Self-XSS es una forma de vulnerabilidad XSS que se basa en la ingeniería social para engañar a la víctima y lograr que ejecute código JavaScript malicioso en su navegador. Si bien técnicamente no es una verdadera vulnerabilidad XSS, ya que se basa en la ingeniería social para que el usuario ejecute código en lugar de una falla en el sitio web afectado que permita al atacante hacerlo, aún presenta los mismos riesgos que una vulnerabilidad XSS regular si se ejecuta correctamente. ^{[ 18 ]}

El XSS mutado ocurre cuando el atacante inyecta algo que parece seguro, pero que el navegador reescribe y modifica al analizar el marcado. Esto hace que sea extremadamente difícil de detectar o sanear dentro de la lógica de la aplicación del sitio web. Un ejemplo es el reequilibrio de comillas sin cerrar o incluso la adición de comillas a valores sin comillas en las propiedades CSS font-family. ^{[ 19 ]}

Existen varios esquemas de escape que se pueden utilizar según la ubicación de la cadena no confiable dentro de un documento HTML, incluyendo la codificación de entidades HTML, el escape de JavaScript, el escape de CSS y la codificación URL (o porcentual) . ^{[ 20 ]} La mayoría de las aplicaciones web que no necesitan aceptar datos enriquecidos pueden usar el escape para eliminar en gran medida el riesgo de ataques XSS de una manera bastante sencilla.

Realizar la codificación de entidades HTML solo en los cinco caracteres significativos de XML no siempre es suficiente para prevenir muchas formas de ataques XSS; las bibliotecas de codificación de seguridad suelen ser más fáciles de usar. ^{[ 20 ]}

Algunos sistemas de plantillas web entienden la estructura del HTML que producen y seleccionan automáticamente un codificador apropiado. ^{[ 21 ] [ 22 ]}

Muchos operadores de aplicaciones web específicas (por ejemplo, foros y correo web) permiten a los usuarios utilizar marcado HTML. Al aceptar entrada HTML de los usuarios (por ejemplo, ), la codificación de salida (como ) no será suficiente, ya que la entrada del usuario debe ser renderizada como HTML por el navegador (para que se muestre como , en lugar de ). Detener un ataque XSS al aceptar entrada HTML de los usuarios es mucho más complejo en esta situación. A menudo, la entrada HTML no confiable debe pasar por un motor de saneamiento de HTML para garantizar que no contenga código JavaScript potencialmente malicioso.<b>very</b> large&lt;b&gt;very&lt;/b&gt; largevery large<b>very</b> large

Por ejemplo, si un usuario ingresa

< span style = "color : blue; " > Hola mundo </span> <script> alert ( " XSS " ) </script>

Entonces, la aplicación que procesa el marcado puede permitirlo, pero escapar el script cuando se muestra la entrada:<span>

< span style = "color: blue;" > Hola mundo </ span > < script > alert( " XSS " ) < /script >

Muchas validaciones se basan en analizar (incluir en la lista negra) etiquetas HTML específicas "en riesgo", como la etiqueta <p> , <div> y <div>, o en permitir solo ciertas etiquetas y eliminar o escapar otras.<iframe><link><script>

Este enfoque presenta varios problemas; por ejemplo, a veces se omiten etiquetas aparentemente inofensivas que, incluso utilizándose correctamente, pueden dar lugar a una vulnerabilidad XSS.

Otro método popular es eliminar la entrada del usuario de " y ', sin embargo, esto también se puede eludir ya que la carga útil se puede ocultar con ofuscación .

Además del filtrado de contenido, también se utilizan comúnmente otros métodos imperfectos para mitigar el cross-site scripting. Un ejemplo es el uso de controles de seguridad adicionales al manejar la autenticación de usuarios basada en cookies . Muchas aplicaciones web dependen de las cookies de sesión para la autenticación entre solicitudes HTTP individuales, y dado que los scripts del lado del cliente generalmente tienen acceso a estas cookies, los exploits XSS simples pueden robarlas. ^{[ 23 ]} Para mitigar esta amenaza en particular (aunque no el problema XSS en general), muchas aplicaciones web vinculan las cookies de sesión a la dirección IP del usuario que inició sesión originalmente, y luego solo permiten que esa IP use esa cookie. ^{[ 24 ]} Esto es efectivo en la mayoría de las situaciones (si un atacante solo busca la cookie), pero obviamente falla en situaciones en las que un atacante está detrás de la misma dirección IP NAT o proxy web que la víctima, o la víctima está cambiando su IP móvil . ^{[ 24 ]}

Si bien los desarrolladores de Web 2.0 y Ajax requieren el uso de JavaScript, ^{[ 26 ]} algunas aplicaciones web están escritas para permitir su funcionamiento sin necesidad de scripts del lado del cliente. ^{[ 27 ]} Esto permite a los usuarios, si así lo desean, deshabilitar los scripts en sus navegadores antes de usar la aplicación. De esta manera, incluso los scripts del lado del cliente potencialmente maliciosos podrían insertarse sin escape en una página, y los usuarios no serían vulnerables a ataques XSS.

Algunos navegadores o complementos de navegador se pueden configurar para deshabilitar los scripts del lado del cliente por dominio. Este enfoque tiene un valor limitado si se permite el uso de scripts por defecto, ya que bloquea los sitios maliciosos solo después de que el usuario sabe que son maliciosos, lo cual es demasiado tarde. Una funcionalidad que bloquea todos los scripts e inclusiones externas por defecto y luego permite al usuario habilitarlos por dominio es más efectiva. Esto ha sido posible durante mucho tiempo en Internet Explorer (desde la versión 4) mediante la configuración de sus llamadas "Zonas de seguridad" ^{[ 28 ]} y en Opera (desde la versión 9) mediante sus "Preferencias específicas del sitio" ^{[ 29 ]} . Una solución para Firefox y otros navegadores basados ​​en Gecko es el complemento de código abierto NoScript que, además de la capacidad de habilitar scripts por dominio, proporciona cierta protección XSS incluso cuando los scripts están habilitados ^{[ 30 ] .}

El problema más significativo de bloquear todos los scripts en todos los sitios web por defecto es la reducción sustancial de la funcionalidad y la capacidad de respuesta (la programación del lado del cliente puede ser mucho más rápida que la programación del lado del servidor porque no necesita conectarse a un servidor remoto y la página o el marco no necesitan recargarse). ^{[ 31 ]} Otro problema con el bloqueo de scripts es que muchos usuarios no lo entienden y no saben cómo proteger adecuadamente sus navegadores. Otra desventaja es que muchos sitios no funcionan sin programación del lado del cliente, lo que obliga a los usuarios a deshabilitar la protección para ese sitio y expone sus sistemas a vulnerabilidades. ^{[ 32 ]} La extensión Firefox NoScript permite a los usuarios permitir scripts selectivamente de una página determinada mientras que deniega otros en la misma página. Por ejemplo, se podrían permitir los scripts de example.com, mientras que los scripts de advertisingagency.com que intentan ejecutarse en la misma página podrían denegarse. ^{[ 33 ]}

Los tipos de confianza ^{[ 34 ]} modifican las API web para comprobar que los valores se hayan registrado como de confianza.  Mientras los programas solo registren como de confianza valores, un atacante que controle un valor de cadena de JavaScript no podrá provocar XSS.  Los tipos de confianza están diseñados para que los equipos azules puedan auditarlos .

Otro enfoque de defensa consiste en utilizar herramientas automatizadas que eliminen el código malicioso XSS de las páginas web. Estas herramientas utilizan análisis estático y/o métodos de coincidencia de patrones para identificar códigos potencialmente maliciosos y protegerlos mediante métodos como el escape. ^{[ 35 ]}

Cuando se establece una cookie con el SameSite=Strictparámetro, se elimina de todas las solicitudes de origen cruzado. Cuando se establece con SameSite=Lax, se elimina de todas las solicitudes de origen cruzado no "seguras" (es decir, solicitudes distintas de GET, OPTIONS y TRACE que tienen semántica de solo lectura). ^{[ 36 ]} La función está implementada en Google Chrome desde la versión 63 y en Firefox desde la versión 60. ^{[ 37 ]}