Las secuencias de comandos entre sitios ( XSS ) son 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 páginas web vistas por 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 . Durante la segunda mitad de 2007, XSSed documentó 11.253 vulnerabilidades entre sitios específicos, en comparación con 2.134 vulnerabilidades "tradicionales" documentadas por Symantec . [1] Los efectos XSS varían 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 .
OWASP considera que el término scripting entre sitios es inapropiado . Inicialmente fue un ataque que se utilizó para violar datos entre sitios, pero gradualmente comenzó a incluir otras formas de ataques de inyección de datos. [2]
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 establece que si al contenido de un sitio (como https://mybank.example1.com ) se le concede permiso para acceder a recursos (como cookies, etc.) en un navegador web, entonces el contenido de cualquier URL con el mismo (1) URI esquema (por ejemplo, ftp, http o https), (2) nombre de host y (3) número de puerto compartirán estos permisos. Al contenido de las URL en las que cualquiera de estos tres atributos sea diferente se le deberán conceder permisos por separado. [3]
Los ataques de secuencias de comandos entre sitios utilizan vulnerabilidades conocidas en las aplicaciones basadas en web , sus servidores o los sistemas de complementos en los que dependen. Al explotar uno de estos, los atacantes incorporan contenido malicioso al 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 bajo 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 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. [4] La expresión "secuencias de comandos entre sitios" originalmente se refería al acto de cargar la aplicación web de terceros atacada desde un sitio de ataque no relacionado. de una manera que ejecute 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 amplió gradualmente para abarcar otros modos de inyección de código, incluidos vectores persistentes y no JavaScript (incluidos ActiveX , Java , VBScript , Flash o incluso scripts HTML ), lo que provocó cierta confusión entre los recién llegados al campo de la seguridad de la información . [5]
Las vulnerabilidades XSS se han reportado y explotado desde la década de 1990. Los sitios destacados afectados en el pasado incluyen los sitios de redes sociales Twitter [6] y Facebook . [7] 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 reportada públicamente, [8] y algunos investigadores estimaron en 2007 que hasta el 68% de los sitios web probablemente estén abiertos a ataques XSS. [9]
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).
La vulnerabilidad de secuencias de comandos entre sitios no persistente (o reflejada ) es, con diferencia, el tipo más básico de vulnerabilidad web. [10] Estos agujeros aparecen cuando los datos proporcionados por un cliente web, [11] más comúnmente en parámetros de consulta HTTP (por ejemplo, envío de formulario HTML), son utilizados inmediatamente por scripts del lado del servidor para analizar y mostrar una página de resultados para y a ese usuario, sin desinfectar adecuadamente el contenido. [12]
Debido a que los documentos HTML tienen una estructura plana y en serie que combina declaraciones de control, formato y el contenido real, cualquier dato no validado proporcionado por el usuario incluido en la página resultante sin la codificación HTML adecuada puede provocar una inyección de marcado. [10] [12] Un ejemplo clásico de un vector potencial es un motor de búsqueda de un sitio: si uno busca una cadena, la cadena de búsqueda normalmente se volverá a mostrar palabra por palabra 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 falla de secuencias de comandos entre sitios. [13]
Un ataque reflejado normalmente se envía por correo electrónico o por 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 confiable es vulnerable al vector, hacer clic en el enlace puede hacer que el navegador de la víctima ejecute el script inyectado.
La vulnerabilidad XSS persistente (o almacenada ) es una variante más devastadora de una falla de secuencias de comandos entre sitios: ocurre cuando el servidor guarda los datos proporcionados por el atacante y luego se muestran permanentemente en páginas "normales" devueltas a otros usuarios en el curso de la navegación normal, sin el escape HTML adecuado. Un ejemplo clásico de esto son los foros de mensajes en línea donde los usuarios pueden publicar mensajes en formato HTML para que otros usuarios los lean. [12]
Por ejemplo, supongamos que hay un sitio web de citas donde los miembros escanean los perfiles de otros miembros para ver si parecen 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 inicia sesión y no puede ver los 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 hacerlo, escribe un script diseñado para ejecutarse desde los navegadores de otros usuarios cuando 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 el script está incluido dentro de un <script>elemento, no se mostrará en la pantalla. Entonces supongamos que Bob, un miembro del sitio de citas, llega al perfil de Mallory, que tiene su respuesta a la pregunta de la primera cita. El navegador ejecuta automáticamente su script y roba una copia del nombre real y del correo electrónico de Bob directamente desde su propia máquina.
Las vulnerabilidades XSS persistentes pueden ser más importantes que otros tipos porque el script malicioso de un atacante se genera 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 del lado del cliente . [14]
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 dicho agujero. Cualquier dato recibido por la aplicación web (por 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 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 devolvería 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 parte de la lógica de presentación (tal vez escrita en JavaScript ) trabajando en el lado del cliente y extrayendo datos, bajo demanda, del servidor usando AJAX .
Como el código JavaScript también procesaba la entrada del usuario y la representaba en el contenido de la página web, comenzó a aparecer una nueva subclase de ataques XSS reflejados que se denominó secuencias de comandos 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. [15]
Un ejemplo de vulnerabilidad XSS basada en DOM es el error encontrado en 2011 en varios complementos de jQuery . [16] Las estrategias de prevención para 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). [17] Algunos marcos de JavaScript tienen contramedidas integradas contra este y otros tipos de ataques, por ejemplo AngularJS . [18]
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 a que se basa en la ingeniería social de un usuario para ejecutar código en lugar de una falla en el sitio web afectado que permite a un atacante hacerlo, aún presenta los mismos riesgos que una vulnerabilidad XSS normal si correctamente ejecutado. [19]
El XSS mutado ocurre cuando el atacante inyecta algo que aparentemente es seguro pero que el navegador 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 abiertas o incluso agregar comillas a los parámetros sin comillas en los parámetros de la familia de fuentes CSS.
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 entidades HTML, el escape de JavaScript, el escape de CSS y la codificación de URL (o porcentaje) . [20] La mayoría de las aplicaciones web que no necesitan aceptar datos enriquecidos pueden utilizar el sistema de 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 XML significativos no siempre es suficiente para evitar 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 comprenden la estructura del HTML que producen y seleccionan automáticamente un codificador apropiado. [21] [22] [23]
Muchos operadores de determinadas aplicaciones web (por ejemplo, foros y correo web) permiten a los usuarios utilizar un subconjunto limitado de marcas HTML. Al aceptar entradas HTML de los usuarios (por ejemplo, <b>very</b> large), la codificación de salida (como <b>very</b> 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 al aceptar 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 listas negras) etiquetas HTML específicas "en riesgo", como la etiqueta iframe , el enlace y la etiqueta script.
Hay varios problemas con este enfoque, por ejemplo, a veces se pueden omitir etiquetas aparentemente inofensivas que, cuando se utilizan correctamente, aún pueden generar un XSS.
Otro método popular es eliminar 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 .
Además del filtrado de contenido, también se utilizan habitualmente 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, simples exploits XSS pueden robar estas cookies. [24] Para mitigar esta amenaza 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. [25] 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 su IP móvil . [25]
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 un indicador 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 prevenir completamente el robo de cookies ni evitar ataques dentro del navegador. [26]
Si bien los desarrolladores de Web 2.0 y Ajax requieren el uso de JavaScript, [27] algunas aplicaciones web están escritas para permitir su funcionamiento sin necesidad de scripts del lado del cliente. [28] Esto permite a los usuarios, si así lo desean, desactivar las secuencias de comandos en sus navegadores antes de utilizar 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 susceptibles 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 permiten secuencias de comandos de forma predeterminada, ya que bloquea los sitios malos sólo 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 al usuario habilitarlas por dominio es más efectiva. Esto ha sido posible durante mucho tiempo en Internet Explorer (desde la versión 4) configurando las llamadas "Zonas de seguridad", [29] y en Opera (desde la versión 9) usando sus "Preferencias específicas del sitio". [30] 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. [31]
El problema más importante al bloquear todos los scripts en todos los sitios web de forma predeterminada es la reducción sustancial de la funcionalidad y la capacidad de respuesta (los scripts del lado del cliente pueden ser mucho más rápidos que los del lado del servidor porque no necesitan conectarse a un servidor remoto ni a la página o marco) . no es necesario recargarlo). [32] 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 desactivar la protección de ese sitio y abre sus sistemas a vulnerabilidades. [33] 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 secuencias de comandos de ejemplo.com, mientras que se podrían no permitir secuencias de comandos de publicidadagency.com que intenten ejecutarse en la misma página. [34]
La Política de seguridad de contenido (CSP) permite que los documentos HTML opten por deshabilitar algunas secuencias de comandos y dejen otras habilitadas. [35] El navegador compara cada script con una política antes de decidir si ejecutarlo. Siempre que la política solo permita scripts confiables y no permita la carga dinámica de código , el navegador no ejecutará programas de autores que no sean de confianza, independientemente de la estructura del documento HTML.
Las políticas CSP modernas permiten usar nonces para marcar scripts en el documento HTML como seguros para ejecutar en lugar de mantener la política completamente separada del contenido de la página. [36] [37] Mientras 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 que han implementado con éxito políticas no basadas en ONCE. [38] [39]
Los tipos confiables [40] cambian las API web para verificar que los valores se hayan registrado como confiables. Mientras los programas solo registren valores confiables, un atacante que controle un valor de cadena de JavaScript no puede causar XSS. Los tipos confiables están diseñados para que los equipos azules puedan auditarlos .
Otro enfoque de defensa es utilizar herramientas automatizadas que eliminen el código malicioso XSS en 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. [41]
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 que no sean "seguras" (es decir, solicitudes distintas de GET, OPTIONS y TRACE que tienen semántica de solo lectura). [42] La función está implementada en Google Chrome desde la versión 63 y Firefox desde la versión 60. [43]
El 16 de enero de 2000, se sugirieron y rebotaron los siguientes nombres entre un pequeño grupo de ingenieros de seguridad de Microsoft: [...] Al día siguiente hubo consenso: Cross Site Scripting.