Blog · Publicado originalmente en inglés el .
Un sitio publicado es un archivo que escribió un desconocido. Se ejecuta en un navegador, lo que significa que ejecuta JavaScript, lo que significa que puede hacer todo lo que el navegador le permite al origen desde el que se sirve. Esa última parte de la frase es todo el diseño.
Lo que vale un origen
Los navegadores no protegen a los archivos unos de otros. Protegen a los orígenes unos de otros: el esquema, el host y el puerto juntos. Las cookies, el almacenamiento local y la posibilidad de leer la respuesta de otro sitio se detienen en ese límite, y dentro de él no hay ningún límite.
Así que, si un sitio que alguien publicó se sirviera desde el mismo host que la aplicación en la que la gente inicia sesión, estaría dentro del origen de la aplicación. No cerca. Dentro. Cada cookie que usa la sesión iría adjunta a sus solicitudes, y el propio sitio podría hacer esas solicitudes.
El camino de limpiar el archivo, en breve
La alternativa es quitarle al archivo lo que es peligroso. Intentamos quererlo, porque es la versión en la que todo vive en un solo dominio y todo el producto es más pequeño.
No sobrevive al contacto con el trabajo real. Los archivos que la gente publica son paneles, calculadoras y pequeñas aplicaciones. El script es la cosa. Quitarlo deja una captura de pantalla. Y limpiar HTML lo bastante bien como para ser un límite de seguridad es un problema con un largo historial público de gente que perdió.
Lo que cuesta separarlos
Dos certificados, uno de ellos comodín (wildcard), que no se puede emitir demostrando el control de un solo nombre de host y por eso necesita un token de DNS. Dos juegos de variables de entorno. Cada conexión entre las dos mitades es entre orígenes distintos, así que todo lo que tiene que cruzar lleva un token firmado, de vida corta y con una sola tarea.
También cuesta una pequeña dosis permanente de confusión: la aplicación está en un nombre y los sitios que publica están en otro, y nadie llega esperándolo.
Lo que se gana
Un sitio publicado puede ser tan hostil como quiera su autor y aun así no alcanzar nada. No puede leer tus cookies, porque no son sus cookies. No puede llamar a la API como si fuera tú, porque el navegador no le envía tus credenciales. No puede reescribir la página que lo rodea, porque no hay ningún sitio alrededor: el marco en el que vive es otro origen.
Y significa que podemos decir que sí por defecto. Lo que se sube no tiene que inspeccionarse en busca de hostilidad antes de poder ejecutarse, porque ejecutarse no es la parte peligrosa. Dónde se ejecuta, sí.
Dónde está el límite, en la ayuda.
Preguntas
¿Por qué Solta usa dos dominios?
Porque un sitio publicado es un archivo que escribió un desconocido, y puede hacer todo lo que el navegador le permite al origen desde el que se sirve. En el mismo host que la aplicación, estaría dentro del origen de la aplicación, junto a tu sesión.
¿Un sitio publicado puede leer mis cookies de Solta?
No. Se sirve desde otro origen, así que tus cookies no son suyas, y el navegador no le envía tus credenciales. Tampoco puede llamar a la API como si fuera tú.
¿Por qué no quitarles a los archivos lo que es peligroso?
Porque los archivos que la gente publica son paneles, calculadoras y pequeñas aplicaciones, y el script es la cosa. Quitarlo deja una captura de pantalla. Y limpiar HTML lo bastante bien como para ser un límite de seguridad tiene un largo historial público de gente que perdió.
¿Qué cuestan los dos dominios?
Dos certificados, uno de ellos comodín, que necesita un token de DNS. Dos juegos de variables de entorno. Y todo lo que pasa de una mitad a la otra lleva un token firmado, de vida corta y con una sola tarea.
¿Hay que inspeccionar un sitio antes de que pueda ejecutarse?
No en busca de hostilidad. Ejecutarse no es la parte peligrosa, dónde se ejecuta sí. Por eso Solta puede decir que sí por defecto.