
Con el reciente lanzamiento de Chrome 83 y el próximo lanzamiento de Mozilla Firefox 79, los desarrolladores web están obteniendo nuevos y potentes mecanismos de seguridad para proteger sus aplicaciones de vulnerabilidades web comunes. En esta publicación compartimos cómo nuestro equipo de Ingeniería de Seguridad de la Información está implementando Tipos de confianza, Política de seguridad de contenido, Obtener encabezados de solicitud de metadatos y el Política de apertura cruzada en Google para ayudar a guiar e inspirar a otros desarrolladores a adoptar de manera similar estas funciones para proteger sus aplicaciones.
Historia
Desde el advenimiento de las aplicaciones web modernas, como clientes de correo electrónico o editores de documentos accesibles en su navegador, los desarrolladores han estado lidiando con vulnerabilidades web comunes que pueden permitir que los datos del usuario sean víctimas de los atacantes. Si bien la plataforma web proporciona un aislamiento sólido para el sistema operativo subyacente, el aislamiento entre las aplicaciones web es una historia diferente. Problemas como XSS, CSRF y fugas a través del sitio se han convertido en facetas desafortunadas del desarrollo web, que afectan a casi todos los sitios web en algún momento.
Estas vulnerabilidades son consecuencias no deseadas de algunas de las características más maravillosas de la web: componibilidad, apertura y facilidad de desarrollo. En pocas palabras, la visión original de la web como malla de documentos interconectados No anticipó la creación de un ecosistema vibrante de aplicaciones web que manejen datos privados para miles de millones de personas en todo el mundo. En consecuencia, las capacidades de seguridad de la plataforma web destinadas a ayudar a los desarrolladores a proteger los datos de sus usuarios han evolucionado lentamente y solo proporcionan protecciones parciales contra fallas comunes.
Los desarrolladores web han compensado tradicionalmente las deficiencias de la plataforma mediante la construcción de herramientas y procesos de ingeniería de seguridad adicionales para proteger sus aplicaciones de fallas comunes; Dicha infraestructura a menudo ha resultado costosa de desarrollar y mantener. A medida que la web continúa cambiando para ofrecer a los desarrolladores capacidades más impresionantes, y las aplicaciones web se vuelven más críticas para nuestras vidas, nos encontramos con una creciente necesidad de mecanismos de seguridad más potentes y abarcadores integrados directamente en la plataforma web.
En los últimos dos años, los fabricantes de navegadores y los ingenieros de seguridad de Google y otras compañías han colaborado en el diseño e implementación de varias características de seguridad importantes para defenderse contra fallas web comunes. Estos mecanismos, en los que nos centramos en esta publicación, protegen contra las inyecciones y ofrecen capacidades de aislamiento, abordando dos fuentes principales de inseguridad en la web.
Vulnerabilidades de inyección
En el diseño de sistemas, mezclar código y datos es uno de los antipatrones de seguridad canónicos, lo que causa vulnerabilidades de software ya en la década de 1980. Es la causa raíz de vulnerabilidades como inyección SQL y comando de inyección, permitiendo el compromiso de bases de datos y servidores de aplicaciones.
En la web, el código de la aplicación se ha entrelazado históricamente con los datos de la página. Marcado HTML como elements or event handler attributes (onclick or onload) allow JavaScript execution; even the familiar URL can carry code and result in script execution when navigating to a javascript: link. While sometimes convenient, the upshot of this design is that – unless the application takes care to protect itself – data used to compose an HTML page can easily inject unwanted scripts and take control of the application in the user's browser.
Addressing this problem in a principled manner requires allowing the application to separate its data from code; this can be done by enabling two new security features: Trusted Types and Content Security Policy based on script nonces.
Trusted Types
Main article: web.dev/trusted-types by Krzysztof Kotowicz
JavaScript functions used by developers to build web applications often rely on parsing arbitrary structure out of strings. A string which seems to contain data can be turned directly into code when passed to a common API, such as innerHTML. This is the root cause of most DOM-based XSS vulnerabilities.
Trusted Types make JavaScript code safe-by-default by restricting risky operations, such as generating HTML or creating scripts, to require a special object – a Trusted Type. The browser will ensure that any use of dangerous DOM functions is allowed only if the right object is provided to the function. As long as an application produces these objects safely in a central Trusted Types policy, it will be free of DOM-based XSS bugs.
You can enable Trusted Types by setting the following response header:
We have recently launched Trusted Types for all users of My Google Activity and are working with dozens of product teams across Google as well as JavaScript framework owners to make their code support this important safety mechanism.
Trusted Types are supported in Chrome 83 and other Chromium-based browsers, and a polyfill is available for other user agents.
Content Security Policy based on script nonces
Main article: Reshaping web defenses with strict Content Security Policy
Content Security Policy (CSP) allows developers to require every