Autenticar y autorizar una conexión persistente

En HTTP de toda la vida cada petición es independiente: la cookie o la cabecera de autorización viajan en cada una, y el servidor puede cambiar de opinión en la siguiente. Una conexión persistente —un WebSocket, o un flujo de eventos del servidor que se queda abierto— funciona al revés. Empieza con una petición HTTP normal, el handshake, y si el servidor la acepta, el canal queda abierto y los mensajes ya no llevan cabeceras propias.

Eso significa que la identidad se decide en ese primer momento y el servidor la asocia al canal. El protocolo de WebSocket no impone ningún método para autenticar: deja que el servidor use cualquiera de los que usaría un servidor HTTP (cookies, autenticación HTTP, certificados de cliente). La consecuencia práctica es que cerrar sesión, cambiar de rol o bloquear la cuenta no alcanza a una conexión ya abierta salvo que alguien en el servidor se encargue de cortarla.

El navegador no deja poner cabeceras propias al abrir un WebSocket desde JavaScript, así que muchos equipos emiten desde la web un ticket y lo mandan en la dirección del handshake. Funciona, pero una dirección se escribe en sitios donde una cabecera no: el registro de acceso del proxy, el historial, las herramientas de monitoreo. Si ese ticket sirve para abrir la conexión, quien lea esos registros también puede abrirla.

Abre el laboratorio. Lee ws-autenticacion.js y luego registro-proxy.txt, y fíjate en la nota del encargo sobre quién consulta ese registro.

Un ticket para abrir una conexión debería parecerse a una entrada de cine: se emite desde una sesión ya autenticada, vale para un solo uso y caduca en segundos o pocos minutos. El código de Corotos hace lo contrario en dos puntos, y los dos están comentados con su motivo. Cruza registro-tickets.txt con registro-conexiones.txt: para cada ticket, mira desde qué dirección se pidió y desde qué direcciones se usó.

Una reconexión desde la misma dirección y con una sesión abierta en la web es lo esperable. Lo que buscas es otra cosa.

El comentario final de ws-autenticacion.js lo admite: cerrar sesión en la web no avisa al servicio de seguimiento. Busca en registro-sesiones.txt los cierres de sesión, compáralos con la hora de cierre de las conexiones de esa misma cuenta y confirma con eventos-enviados.txt si después del cierre siguieron saliendo mensajes. Una de las dos cuentas que cerraron sesión por la mañana lo hizo en un equipo compartido.

Los requisitos de WebSocket del estándar de verificación de OWASP (ASVS 5.0, sección V4.4) piden, en esencia, conexiones cifradas, origen comprobado, y que si la sesión normal no sirve para el canal, los tokens propios del canal se obtengan o validen a través de la sesión HTTPS ya autenticada y cumplan las mismas reglas que una sesión. Una de esas reglas es que lo que se revoca deja de valer.