Aprendí a amar la Política del Mismo Origen
Este año pasé una buena parte de mi vida laboral intentando (en colaboración con el increíble Noam Rosenthal ) estandarizar una nueva característica de la plataforma web: una forma de modificar el tamaño intrínseco y la resolución de las imágenes. ¡Y oye! ¡Lo hicimos! Pero vaya, ¿alguna vez fue una experiencia de aprendizaje ?
Este no fue mi primer rodeo de estandarización, por lo que más o menos anticipé muchos de los problemas con los que nos topamos. Fuertes comentarios negativos de los navegadores. Errores extraños e imprevistos con las primitivas subyacentes. Uno o dos replanteamientos completos . Sin embargo, lo que no anticipé fue que nuestra propuesta, que, nuevamente, “sólo” trataba de modificar el tamaño de visualización predeterminado de las imágenes, entraría en conflicto con los principios fundamentales de privacidad y seguridad de la web. Porque antes de este año, realmente no entendía esos principios.
Déjame poner un poco la mesa. ¿Qué estábamos tratando de hacer?
De forma predeterminada, las imágenes en la web aparecen exactamente tan grandes como son. ¿Incrustar una imagen de 800 × 600? A menos que estire o reduzca esa imagen con CSS o marcado , ese es exactamente el tamaño que tendrá: 800 píxeles CSS de ancho y 600 píxeles CSS de alto. Ese es el tamaño intrínseco (también conocido como “natural” ) de la imagen . Otra forma de decirlo es que, de forma predeterminada, todas las imágenes de la web tienen una densidad intrínseca de 1×.
Eso está muy bien, hasta que intentas ofrecer imágenes de densidad alta , baja o ✨variable✨ , sin acceso a CSS o HTML. Esta es una situación en la que se encuentran con bastante frecuencia los servidores de imágenes como mi empleador, Cloudinary .
Entonces, nos propusimos brindarnos a nosotros mismos y al resto de la web una herramienta para modificar el tamaño intrínseco y la resolución de las imágenes. Después de un par de replanteamientos, la solución a la que llegamos fue la siguiente:
- Los navegadores deben leer y aplicar los metadatos contenidos en los recursos de imágenes , permitiéndoles declarar el tamaño y la resolución de visualización que desean.
- Siguiendo los pasos recientes
image-orientation
, de forma predeterminada, los navegadores respetarían y aplicarían estos metadatos. Pero puedes anularlo o desactivarlo con un poco de CSS (image-resolution
) o marcado ( descriptoressrcset
dex
).
Nos sentimos bastante bien con esto. Fue flexible, se basó en un patrón existente y parecía abordar todas las cuestiones que se habían planteado en contra de nuestras propuestas anteriores. Por desgracia, una de las editoras de la especificación HTML, Anne van Kesteren , dijo: no. Esto no iba a funcionar . Y image-orientation
también necesitaba un replanteamiento urgente . Porque este patrón, en el que puedes activar y desactivar los efectos de los metadatos EXIF con CSS y HTML, violaría la ” Política del mismo origen “.
¿Cómo?
¿No estamos simplemente escalando y rotando imágenes?
¡Hora de confesarse! Antes de todo esto, más o menos había comparado la Política del mismo origen con los errores de CORS y toda la frustración que me han causado a lo largo de los años. Ahora, sin embargo, la Política del Mismo Origen no sólo se interponía entre mí y la gestión de un fetch
, sino que estaba retrasando una importante iniciativa de trabajo. Y tuve que explicar la situación a jefes que sabían incluso menos que yo sobre seguridad y privacidad en la web. ¡Tiempo de aprender!
Esto es lo que aprendí:
- La Política del Mismo Origen no es una regla única y simple. Y ciertamente no son == errores CORS.
- Lo que es es una filosofía que ha evolucionado con el tiempo y se ha implementado de manera inconsistente en toda la plataforma web.
- En general, lo que dice es: el límite fundamental de seguridad y privacidad de la web son los orígenes . ¿Compartes un origen con algo más en la web? Puedes interactuar con él como quieras. Sin embargo, si no es así, es posible que tengas que superar algunos obstáculos.
- ¿Por qué podría?” Bueno, ¡se permiten muchas interacciones entre orígenes de forma predeterminada! Generalmente, cuando creas un sitio web, puedes escribir entre orígenes (enviando
POST
solicitudes a quien quieras, a través de formularios). E incluso puede incrustar recursos de distintos orígenes (iframes, imágenes, fuentes, etc.) que los visitantes de su sitio verán, allí mismo, en su sitio web. Pero lo que no puede hacer es mirar esos recursos de origen cruzado usted mismo. No debería poder leer nada sobre un recurso de origen cruzado, en su JavaScript, sin un permiso especialmente otorgado (a través de nuestro viejo amigo, CORS). - Esto es lo que más me sorprendió, una vez que finalmente lo entendí: las lecturas entre orígenes están prohibidas de forma predeterminada porque, como usuarios finales, todos vemos diferentes webs mundiales y un sitio web no debería poder verlas. el resto de la web a través de los ojos de sus visitantes. Los variados contextos de navegación local de las personas (incluidas, entre otras, las cookies) significan que cuando voy, por ejemplo, a gmail.com, veré algo diferente a ti cuando ingreses la misma URL en tu barra de direcciones. y presione “regresar”. Si otros sitios web pudieran enviar solicitudes a Gmail desde mi navegador, con mis cookies, y leer los resultados, bueno, ¡eso sería muy, muy malo!
Entonces, de forma predeterminada: puedes hacer muchas cosas con recursos de origen cruzado. Pero prevenir lecturas de orígenes cruzados es todo el juego. Esos valores predeterminados son más o menos de lo que habla la gente cuando habla de la “Política del Mismo Origen”.
¿Cómo se relaciona todo esto con el tamaño intrínseco y la resolución de las imágenes?
Digamos que hay una URL de imagen https://coolbank.com/hero.jpg
, que devuelve un recurso diferente dependiendo de si un usuario ha iniciado sesión o no en coolbank.com. Y digamos que la versión que aparece cuando estás conectado tiene información de resolución EXIF, pero la versión que aparece cuando no estás conectado, no. Por último, supongamos que soy un malvado phisher, tratando de descubrir a qué banco perteneces, para poder falsificar su página de inicio y engañarte para que escribas la información de inicio de sesión de tu banco en mi forma malvada.
¡Entonces! Me inserto https://coolbank.com/hero.jpg
en una página malvada. Compruebo su tamaño intrínseco. Desactivo el tamaño EXIF con image-resolution: none
y luego compruebo su tamaño nuevamente. Ahora, aunque las restricciones de CORS me impiden ver los datos de píxeles de la imagen, sé si contiene o no información de resolución EXIF: he podido leer una pequeña parte de esa imagen, en todos los orígenes. Y ahora sé si ha iniciado sesión o no y tiene una cuenta en coolbank.com.
¿Inverosímil? ¡Tal vez! Pero la web es un lugar inimaginablemente grande. Y, como dijo una vez Jen Simmons,
Esta es una de las mejores y más importantes cosas de LA WEB. Vaya a un sitio web, está a salvo de malware. Descarga una aplicación, estás en riesgo. No puedes descargar aplicaciones aleatorias desde lugares aleatorios. Puede ir a sitios web aleatorios y esperar estar seguro. Debemos luchar para mantener la web así. https://t.co/xKQ5vVNCaU
– Jen Simmons (@jensimmons) 11 de marzo de 2020
Navegar por la web consiste básicamente en ejecutar código potencialmente malicioso y que no es de confianza de otras personas, lo quiera o no, durante todo el día. Los principios que subyacen a la seguridad y la privacidad web (incluida la Política del Mismo Origen) permiten esta seguridad y deben defenderse absolutamente. El agujero que intentábamos abrir involuntariamente en la Política del Mismo Origen parecía muy pequeño al principio. Algunos fragmentos literales de información aparentemente inofensiva. Pero una lectura entre orígenes, por pequeña que sea, es una lectura entre orígenes y no se permiten lecturas entre orígenes .
¿Cómo arreglamos nuestra especificación? Hicimos que la información de orientación y resolución EXIF fuera ilegible en todos los orígenes al hacerla imposible de desactivar: en contextos de orígenes cruzados, las modificaciones EXIF siempre se aplican. Una imagen de 800 × 600 cuyo EXIF dice que debe tratarse como 400 × 300 se comportará exactamente como una imagen de 400 × 300, pase lo que pase. Una solución bastante sencilla, una vez que comprendamos el problema.
Como beneficio adicional, una vez que entendí realmente la Política del Mismo Origen y los porqués detrás de las políticas de seguridad predeterminadas de la web, muchas otras piezas de seguridad web comenzaron a encajar para mí.
Los ataques de falsificación de solicitudes entre sitios aprovechan el hecho de que se permiten escrituras entre orígenes de forma predeterminada. Si un punto final API no tiene cuidado con la forma en que responde a POST
las solicitudes, pueden suceder cosas malas. Del mismo modo, la Política de seguridad de contenido permite un control granular sobre qué tipos de incrustaciones están permitidas, porque nuevamente, de forma predeterminada, todas lo están, y resulta que eso abre la puerta a ataques de secuencias de comandos entre sitios . Y la nueva sopa de letras de características de seguridad web ( COOP , COEP , CORP y CORB ) tiene como objetivo cerrar por completo las interacciones entre orígenes , solucionar algunas de las formas inconsistentes en que se ha implementado la Política del Mismo Origen a lo largo de los años y cerrar reducir cualquier/todas las posibles interacciones entre orígenes, para lograr un estado enrarecido conocido como “aislamiento entre orígenes” . En un mundo donde Spectre y sus amigos quieren decir que la carga entre orígenes se puede aprovechar para realizar lecturas entre orígenes , se necesita un aislamiento total entre orígenes para garantizar la seguridad al hacer varias cosas nuevas y poderosas.
En breve:
- La seguridad y la privacidad en la web son realmente sorprendentes, si lo piensas.
- Son producto de las políticas predeterminadas de la plataforma, que tienen como objetivo restringir las interacciones entre orígenes .
- De forma predeterminada, lo único que nadie debería poder hacer es leer datos entre orígenes (sin un permiso especial).
- La razón por la que las lecturas están prohibidas es que todos vemos webs diferentes y los atacantes no deberían poder ver la web a través de los ojos de las víctimas potenciales.
- ¡Sin dudas, quejas o peros! Cualquier agujero en la Política del Mismo Origen, por pequeño que sea, es una superficie propicia para el abuso.
- En 2020, intenté abrir un pequeño agujero en la Política del Mismo Origen (ups) y luego aprendí todo lo anterior.
Por un 2021 más seguro y protegido, en todos los sentidos posibles.
Deja un comentario