Fecha de publicación: 4 de mayo de 2020
En Cómo hacer que tu sitio web esté "aislado de origen cruzado" con COOP y COEP explicamos cómo adoptar el estado "aislado de origen cruzado" con COOP y COEP. Este es un artículo complementario que explica por qué se requiere el aislamiento de origen cruzado para habilitar funciones potentes en el navegador.
Glosario
En este documento, se usa mucha terminología abreviada y con nombres similares. Para aclarar, seleccionamos un miniglosario:
- COEP: Política de incorporaciones de origen cruzado
- COOP: Política de abridor de origen cruzado
- CORP: Política de recursos de origen cruzado
- CORS: Uso compartido de recursos de origen cruzado
- CORB: Bloqueo de lectura de origen cruzado
Fondo
La Web se basa en la política del mismo origen, una
función de seguridad que restringe la forma en que los documentos y las secuencias de comandos pueden interactuar con
los recursos de otro origen. Este principio restringe las formas en que los sitios web pueden acceder a los recursos de origen cruzado. Por ejemplo, se impide que un documento de https://a.example acceda a los datos alojados en https://b.example.
Sin embargo, la política del mismo origen tuvo algunas excepciones históricas. Cualquier sitio web puede hacer lo siguiente:
- Incorporar iframes de origen cruzado
- Incluir recursos de origen cruzado, como imágenes o secuencias de comandos
- Abrir ventanas de diálogo de origen cruzado con una referencia DOM
Cuando la comunidad web se dio cuenta de los beneficios de una política estricta del mismo origen, la Web ya dependía de estas excepciones.
Los efectos secundarios de seguridad de una política del mismo origen tan flexible se corrigieron de dos maneras:
- El protocolo de uso compartido de recursos de origen cruzado (CORS) garantiza que el servidor permita compartir un recurso con un origen determinado.
- Los desarrolladores quitan implícitamente el acceso directo a las secuencias de comandos a los recursos de origen cruzado, mientras conservan la retrocompatibilidad. Estos recursos de origen cruzado se denominan recursos "opacos". Por este motivo, la manipulación de píxeles de origen cruzado con
CanvasRenderingContext2Dfalla, a menos que se aplique CORS a la imagen.
Todas estas decisiones de política se toman dentro de un grupo de contexto de navegación.
Durante mucho tiempo, esta combinación fue suficiente para mantener seguros los navegadores, con casos extremos limitados que necesitaban parches directos (como las vulnerabilidades de JSON).
Esto cambió con
Spectre, que
hace que cualquier dato que se cargue en el mismo grupo de contexto de navegación que tu código sea
potencialmente legible. Si miden el tiempo que tardan ciertas operaciones, los atacantes pueden adivinar el contenido de las memorias caché de la CPU y, por lo tanto, el contenido de la memoria del proceso. Estos ataques son posibles con temporizadores de baja granularidad que existen en la plataforma y se pueden acelerar con temporizadores de alta granularidad, tanto explícitos (como performance.now()) como implícitos (como SharedArrayBuffers).
Si evil.com incorpora una imagen de origen cruzado, puede usar un ataque de Spectre para leer los datos de píxeles de la imagen incorporada. Esto hace que las protecciones que dependen de la "opacidad" sean ineficaces.
Lo ideal es que el servidor que posee el recurso examine todas las solicitudes de origen cruzado. Si no se realiza la revisión, los datos nunca deben llegar al grupo de contexto de navegación de un actor malicioso. Por lo tanto, los datos permanecen fuera del alcance de posibles ataques de Spectre. A esto lo llamamos estado aislado de origen cruzado.
Cuando el código incorporado está en un estado aislado de origen cruzado, el sitio solicitante se considera menos peligroso. Esto permite que el sitio solicitante use
SharedArrayBuffer, performance.measureUserAgentSpecificMemory() y
temporizadores de alta resolución con mejor precisión,
al tiempo que evita posibles ataques de Spectre. Este estado también impide modificar document.domain.
Política de incorporaciones de origen cruzado
La política de incorporaciones de origen cruzado (COEP) impide que un documento cargue recursos de origen cruzado que no le otorguen explícitamente permiso con CORP o CORS. Con esta función, puedes declarar que un documento no puede cargar esos recursos.
a.example,
estableció la política de COEP en require-corp. a.example quiere incorporar 3 recursos de b.example, pero solo dos tienen éxito.
Las dos incorporaciones exitosas incluyen un archivo JavaScript con una política de CORP de origen cruzado y una imagen con CORS permitido. El tercer recurso es un video que tiene una política de CORP que requiere que el recurso se incorpore solo en el mismo origen, por lo que el video no se cargará en a.example.
Para activar esta política, agrega el siguiente encabezado HTTP al documento:
Cross-Origin-Embedder-Policy: require-corp
COEP toma un solo valor de require-corp. Esto aplica la política de que el documento solo puede cargar recursos del mismo origen o recursos marcados explícitamente como cargables desde otro origen.
Para que los recursos se puedan cargar desde otro origen, deben admitir el uso compartido de recursos de origen cruzado (CORS) o la política de recursos de origen cruzado (CORP).
Uso compartido de recursos de origen cruzado
Si un recurso de origen cruzado admite el uso compartido de recursos de origen cruzado
(CORS), puedes usar el
crossorigin
atributo
para cargarlo en tu página web sin que COEP lo bloquee.
<img src="https://third-party.example.com/image.jpg" crossorigin>
Por ejemplo, si este recurso de imagen se entrega con encabezados CORS, usa el
crossorigin atributo para que la solicitud de recuperación del recurso use CORS
modo. Esto también impide que se cargue la imagen, a menos que establezca encabezados CORS.
Del mismo modo, puedes recuperar datos de origen cruzado a través del método fetch(), que
no requiere un manejo especial, siempre que el servidor responda con los encabezados
HTTP
correctos.
Política de recursos de origen cruzado
La política de recursos de origen cruzado (CORP) se introdujo originalmente como una opción para proteger tus recursos de que se carguen desde otro origen. En el contexto de COEP, CORP puede especificar la política del propietario del recurso sobre quién puede cargar un recurso.
El encabezado Cross-Origin-Resource-Policy toma tres valores posibles:
Cross-Origin-Resource-Policy: same-site
Los recursos marcados como same-site solo se pueden cargar desde el mismo sitio.
Cross-Origin-Resource-Policy: same-origin
Los recursos marcados como same-origin solo se pueden cargar desde el mismo origen.
Cross-Origin-Resource-Policy: cross-origin
Cualquier sitio web puede cargar los recursos marcados como cross-origin. (Este
valor se agregó a la
especificación de CORP junto con COEP).
Política de abridor de origen cruzado
La política de abridor de origen cruzado
(COOP) te permite aislar una
ventana de nivel superior de otros documentos, colocando los documentos en un grupo de contexto de navegación independiente. De esta manera, los documentos no pueden interactuar directamente con la ventana de nivel superior. Por ejemplo, si un documento con COOP abre un diálogo, su propiedad window.opener es null. La propiedad .closed de la referencia del abridor es true.
El encabezado Cross-Origin-Opener-Policy toma tres valores posibles:
Cross-Origin-Opener-Policy: same-origin
Los documentos marcados como same-origin pueden compartir el mismo grupo de contexto de navegación con documentos del mismo origen que también están marcados explícitamente como same-origin.
Cross-Origin-Opener-Policy: same-origin-allow-popups
Un documento de nivel superior con same-origin-allow-popups conserva las referencias a cualquiera de sus ventanas emergentes que no establezcan COOP o que inhabiliten el aislamiento estableciendo un COOP de unsafe-none.
Cross-Origin-Opener-Policy: unsafe-none
unsafe-none es el valor predeterminado y permite que el documento se agregue al grupo de contexto de navegación de su abridor, a menos que el abridor tenga un COOP de same-origin.
Resumen
Si deseas acceder a funciones como SharedArrayBuffer,
performance.measureUserAgentSpecificMemory(), o temporizadores
de alta resolución con mejor precisión,
tu documento debe usar COEP con el valor de require-corp y
COOP con el valor de same-origin. En ausencia de cualquiera de ellos, el navegador no garantizará un aislamiento suficiente para habilitar de forma segura esas funciones potentes.
Para determinar la situación de tu página, verifica si
self.crossOriginIsolated
muestra true.
Obtén información para implementar esto en Cómo hacer que tu sitio web esté "aislado de origen cruzado" con COOP y COEP.