Recientemente actualizamos una aplicación web a Django 4 que ahora, de forma predeterminada, agrega un
Cross-Origin-Opener-Policy: same-origin
encabezado a las respuestas http, lo que puede causar window.openerque esté nullen la ventana secundaria. Esto rompió una de nuestras páginas donde teníamos una ventana secundaria (para la autenticación de SSO) que enviaba una postMessage()respuesta a la ventana principal cuando terminaba de hacer su trabajo.
Sé que puedo solucionar eso configurando manualmente ese encabezado en unsafe-none, o estructurando esas páginas de manera diferente, etc., pero tengo curiosidad por saber qué es potencialmente inseguro acerca de que la ventana secundaria tenga acceso a window.opener.
Los navegadores se mantienen window.openerbastante bloqueados, y no hay mucho que las ventanas secundarias puedan hacer aparte de llamar postMessage()y un par de otras cosas menores.
Dado que está tan bloqueado, ¿qué pasa con que no sea seguro? ¿Alguien puede dar un ejemplo de algo dañino que una ventana infantil puede hacer con lo window.opener que el navegador permitirá?
Solución del problema
Esto se menciona brevemente en MDN en la página sobre noopener, que hace referencia a esta publicación de blog.
Citando directamente este blog:
TL; DR Si se establece window.opener, una página puede desencadenar una navegación en el abridor independientemente del origen de la seguridad.
y
Este es un ejemplo relativamente inofensivo, pero en su lugar podría haber redirigido a una página de phishing, diseñada para parecerse al index.html real, solicitando credenciales de inicio de sesión. Es probable que el usuario no se dé cuenta de esto, porque el foco está en la página maliciosa en la nueva ventana mientras la redirección ocurre en segundo plano.
Debe rediseñar el flujo del inicio de sesión para que no necesite el encabezado inseguro. Especialmente si acepta enlaces arbitrarios de los usuarios.
No hay comentarios:
Publicar un comentario