El retorno tras iniciar sesión y su lista de destinos

Casi toda aplicación con sesión guarda un destino de retorno: la persona pidió una página, no tenía sesión, entró y queremos devolverla donde iba. El parámetro que lleva ese destino es una redirección abierta con dos agravantes.

El primero es el momento: el salto ocurre justo después de escribir la contraseña, que es cuando menos se mira la barra de direcciones. El segundo es la apariencia: si el destino imita la pantalla de entrada y pide los datos «otra vez», la repetición no parece rara, porque acaba de pasar algo parecido de verdad.

De ahí la regla de diseño: el destino de retorno no se valida, se elige. La aplicación tiene un conjunto cerrado de sitios a los que devuelve a alguien, y el parámetro sirve para señalar uno de ellos, no para describir una dirección cualquiera.

Abre el laboratorio y lee RetornoController.php. El arreglo del 20 de noviembre extrae el host del destino y comprueba algo sobre él. Después abre registro-retorno.txt y compara cada host con el dominio propio y sus subdominios, que la nota del final del registro deja claros.

Mide el alcance como en las salas anteriores: cuenta los inicios de sesión del registro cuyo host final no es el dominio propio de la editorial ni un subdominio suyo.

destinos-retorno.php es la propuesta del equipo de seguridad: un mapa de claves a rutas del propio portal. El equipo del portal pidió esperar porque «la comprobación del dominio ya cubre el caso». Acabas de ver que no, pero el argumento a favor del mapa no es solo que la comprobación falle hoy.

Un portal rara vez tiene un solo sitio donde decide a dónde enviar a alguien. Antes de cerrar el hallazgo conviene decirle al equipo dónde más mirar, porque el mismo parámetro suele viajar por varios caminos.