Descubra por qué es necesario el aislamiento de origen cruzado para utilizar funciones potentes como SharedArrayBuffer, performance.measureMemory()y la API de autoperfilado de JS.
Seguro y a salvo
Introducción
En Cómo hacer que su sitio web sea «aislado de origen cruzado» utilizando COOP y COEP, explicamos cómo adoptar el estado «aislado de origen cruzado» utilizando 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.
Término clave:
Este artículo utiliza muchas terminologías que suenan similares. Para aclarar las cosas, definámoslas:
Antecedentes
La web se basa en la política del mismo origen: una característica de seguridad que restringe la forma en que los documentos y los scripts pueden interactuar con recursos de otro origen. Este principio restringe las formas en que los sitios web pueden acceder a los recursos de origen cruzado. Por ejemplo, un documento de https://a.example no puede acceder a los datos alojados en https://b.example.
Sin embargo, la política del mismo origen ha tenido algunas excepciones históricas. Cualquier sitio web puede:
- Incrustar iframes de origen cruzado
- Incluya recursos de origen cruzado como imágenes o scripts
- Abrir ventanas emergentes de origen cruzado con una referencia DOM
Si la web pudiera diseñarse desde cero, estas excepciones no existirían. Desafortunadamente, cuando la comunidad web se dio cuenta de los beneficios clave de una política estricta del mismo origen, la web ya confiaba en estas excepciones.
Los efectos secundarios de seguridad de una política tan laxa del mismo origen se corrigieron de dos maneras. Una forma fue mediante la introducción de un nuevo protocolo llamado Uso compartido de recursos de origen cruzado (CORS)
cuyo propósito es asegurarse de que el servidor permita compartir un recurso con un origen determinado. La otra forma es eliminando implícitamente el acceso directo del script a los recursos de origen cruzado mientras se conserva la compatibilidad con versiones anteriores. Estos recursos de origen cruzado se denominan recursos «opacos». Por ejemplo, esta es la razón por la que manipular los píxeles de una imagen de origen cruzado mediante CanvasRenderingContext2D
falla a menos que se aplique CORS a la imagen.
Todas estas decisiones de política están sucediendo dentro de un grupo de contexto de navegación.
Durante mucho tiempo, la combinación de CORS y recursos opacos fue suficiente para que los navegadores fueran seguros. A veces, casos extremos (como Vulnerabilidades JSON) se descubrieron y debían parchearse, pero en general el principio de no permitir el acceso de lectura directo a los bytes sin procesar de los recursos de origen cruzado fue exitoso.
Todo esto cambió con
Espectro, lo que hace que cualquier dato que se cargue en el mismo grupo de contexto de navegación que su código sea potencialmente legible. Si evil.com incrusta una imagen de origen cruzado, pueden usar un ataque Spectre para leer sus datos de píxeles, lo que hace que las protecciones que dependen de la «opacidad» sean ineficaces.
Idealmente, todas las solicitudes de origen cruzado deben ser examinadas explícitamente por el servidor propietario del recurso. Si el servidor propietario de los recursos no proporciona la verificación, los datos nunca llegarán al grupo de contexto de navegación de un actor maligno y, por lo tanto, permanecerán fuera del alcance de cualquier ataque de Spectre que pueda llevar a cabo una página web. Lo llamamos un estado aislado de origen cruzado. Esto es exactamente de lo que se trata COOP + COEP.
En un estado aislado de origen cruzado, el sitio solicitante se considera menos peligroso y esto desbloquea características poderosas como SharedArrayBuffer,
performance.measureMemory y la API JS Self-Profiling que de otra manera podría usarse para ataques tipo Spectre. También evita modificar document.domain.
Política de incrustación de origen cruzado
Política de incrustación de origen cruzado (COEP) evita que un documento cargue recursos de origen cruzado que no otorguen explícitamente el permiso del documento (usando CORP o CORS). Con esta función, puede declarar que un documento no puede cargar dichos recursos.
Para activar esta política, agregue el siguiente encabezado HTTP al documento:
require-corplos require-corp La palabra clave es el único valor aceptado para COEP. 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 Uso compartido de recursos de origen cruzado (CORS), puede utilizar el
crossorigin
atributo
para cargarlo en su página web sin ser bloqueado por COEP.
<img src="https://third-party.example.com/image.jpg" crossorigin>Por ejemplo, si este recurso de imagen se sirve con encabezados CORS, use el
crossorigin atributo para que la solicitud para obtener el recurso utilice Modo CORS. Esto también evita que la imagen se cargue a menos que establezca encabezados CORS.
Del mismo modo, puede obtener datos de origen cruzado a través del fetch() método, que no requiere un manejo especial siempre que el servidor responda con los encabezados HTTP correctos.
Política de recursos de origen cruzado
Política de recursos de origen cruzado (CORP)
se introdujo originalmente como una opción para proteger sus recursos de ser cargados por otro origen. En el contexto de COEP, CORP puede especificar la política del propietario del recurso sobre quién puede cargar un recurso.
los Cross-Origin-Resource-Policy encabezado toma tres valores posibles:
same-siteRecursos que están marcados same-site solo se puede cargar desde el mismo sitio.
same-originRecursos que están marcados same-origin solo se puede cargar desde el mismo origen.
cross-originRecursos que están marcados cross-origin se puede cargar en cualquier sitio web. (Este valor se agregó a la especificación CORP junto con COEP.)
Una vez que agregue el encabezado COEP, no podrá omitir la restricción utilizando trabajadores de servicio. Si el documento está protegido por un encabezado COEP, la política se respeta antes de que la respuesta ingrese al proceso del documento, o antes de que ingrese al trabajador del servicio que está controlando el documento.
Política de apertura de origen cruzado
Política de apertura de origen cruzado (COOP) le permite asegurarse de que una ventana de nivel superior esté aislada de otros documentos colocándolos en un grupo de contexto de exploración diferente, de modo que no puedan interactuar directamente con la ventana de nivel superior. Por ejemplo, si un documento con COOP abre una ventana emergente, su
window.opener la propiedad será null. También el .closed propiedad de la referencia del abridor volverá true.
los Cross-Origin-Opener-Policy encabezado toma tres valores posibles:
same-originDocumentos que están marcados same-origin puede compartir el mismo grupo de contexto de navegación con documentos del mismo origen que también están marcados explícitamente same-origin.
same-origin-allow-popupsUn documento de nivel superior con same-origin-allow-popups conserva referencias a cualquiera de sus ventanas emergentes que no establecen COOP o que optan por salir del aislamiento estableciendo un COOP de unsafe-none.
unsafe-noneunsafe-none es el predeterminado y permite que el documento se agregue al grupo de contexto de exploración de su abridor a menos que el abridor tenga un COOP de same-origin.
los
noopener
El atributo tiene un efecto similar al que cabría esperar de COOP, excepto que funciona solo desde el lado del abridor. (No puede desvincular su ventana cuando la abre un tercero). Cuando adjunta noopener haciendo algo como
window.open(url, '_blank', 'noopener') o <a target="_blank" rel="noopener">, puede disociar deliberadamente su ventana de la ventana abierta.
Mientras noopener puede ser reemplazado por COOP, sigue siendo útil cuando desea proteger su sitio web en navegadores que no admiten COOP.
Resumen
Si desea acceso garantizado a funciones potentes como SharedArrayBuffer,
performance.measureMemory o API de autoperfilado JS, solo recuerde que su 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á el aislamiento suficiente para habilitar de forma segura esas potentes funciones. Puede determinar la situación de su página comprobando si
self.crossOriginIsolated
devoluciones true.
Conozca los pasos para implementar esto en Cómo hacer que su sitio web sea «aislado de origen cruzado» usando COOP y COEP.
Recursos
