Tabnabbing en el webmail Roundcube de Nextcloud: la ventana de redacción podía redirigir la pestaña original

Resumen

El investigador informó al programa de Nextcloud de un caso de reverse tabnabbing en el webmail Roundcube. Cuando una página abre otra en una pestaña o ventana nueva (por ejemplo con target="_blank") sin cortar la relación entre ambas, la página nueva puede alcanzar a la que la abrió mediante la propiedad window.opener y cambiar su dirección sin que el usuario lo note.

En Roundcube, el botón de la pantalla de redacción que abre el correo en una ventana nueva dejaba esa referencia disponible: desde la ventana nueva se podía reescribir la ubicación de la pestaña original del webmail.

El reporte se envió el 2 de octubre de 2025, quedó resuelto y se divulgó el 24 de diciembre de 2025. No constan recompensa, CVE ni CWE.

Pasos de reproducción

1. Iniciar sesión en una cuenta del webmail Roundcube.
2. Entrar en Redactar (Compose) y pulsar el botón que abre la redacción en una ventana nueva.
3. En esa ventana nueva, abrir la consola del navegador y ejecutar:

window.opener.location='http://google.com'

1. Volver a la pestaña original del webmail: ya no muestra Roundcube, sino google.com.

Como escenario de ataque, el investigador plantea una página controlada por el atacante que incluya este código, que redirige la ventana que la abrió (si existe) y también la ventana que la contiene si se carga dentro de un marco:

<script> if (window.opener) window.opener.parent.location.replace('http://phishing.com'); if (window.parent != window) window.parent.location.replace('http://phishing.com'); </script>

Impacto

La redirección ocurre en la pestaña que el usuario dejó atrás, en segundo plano. Al volver a ella esperando encontrar su correo, la víctima puede encontrarse una página falsa que imite la pantalla de inicio de sesión del webmail. Según el investigador, como este tipo de ataque es mucho menos conocido que una redirección abierta, es fácil que el usuario introduzca allí sus credenciales, lo que permitiría al atacante tomar el control de la cuenta.

Remediación

El reporte figura como resuelto, pero no detalla cómo se corrigió.

Qué aprender de este caso

• Revisa cualquier botón o enlace que abra ventanas nuevas, no solo los <a target="_blank">: aquí el punto señalado era la ventana de redacción que abre la propia aplicación. Comprueba en la consola de la ventana nueva si window.opener es distinto de null.
• Para que el escenario de phishing sea real, la página que acaba en la ventana nueva tiene que poder ejecutar código del atacante; al auditar, busca qué contenido externo (enlaces dentro de correos, adjuntos, vistas previas) puede terminar abierto con el opener intacto.
• Al programar, abre las ventanas con rel="noopener noreferrer" en los enlaces o con window.open(url, '_blank', 'noopener'), y valora la cabecera Cross-Origin-Opener-Policy: same-origin para que una página de otro origen no conserve la referencia.
• En un webmail el riesgo es mayor que en otras webs: el usuario vuelve a menudo a la pestaña del correo y una pantalla de "sesión caducada" le resulta creíble.