WebSockets: autenticación y origen

Un canal WebSocket empieza con una petición HTTP normal que pide cambiar de protocolo. El navegador le añade dos cosas que importan: las cookies del sitio de destino y la cabecera Origin con el sitio que abre el canal. Si el servidor acepta, contesta que cambia de protocolo y desde ahí ya no hay peticiones ni respuestas, solo mensajes.

CORS no se aplica a ese canal: el código de cualquier sitio puede abrir un WebSocket hacia otro y leer lo que reciba. La única defensa del lado del servidor es mirar Origin en la apertura y rechazar los sitios que no son suyos. Si no lo hace y la autenticación es por cookie que viaja entre sitios, una página ajena puede abrir el canal con la sesión de quien la visita y leer sus mensajes. La guía de pruebas web de OWASP lo trata en su prueba de WebSockets.

La otra mitad es la autorización: que el canal esté autenticado no quiere decir que cada mensaje lo esté. Si el servidor deja suscribirse a cualquier canal con solo nombrarlo, una cuenta legítima lee lo de otra.

Abre el laboratorio y lee apertura.txt y después prueba-origen.txt. El evaluador repitió la apertura desde el repetidor del proxy cambiando una sola cabecera cada vez. Compara cómo contesta el servidor en cada caso y fíjate en el primer mensaje que llega.

Ahora mensajes.txt. Cada suscripción nombra un canal, y algunos canales llevan el número de una reserva. Las dos cuentas de prueba son del cliente, que las entregó justo para comprobar si una puede ver lo de la otra.

Un WebSocket puede ir cifrado (wss://, como HTTPS) o en claro (ws://, como HTTP). En claro, cualquiera en la misma red ve y puede cambiar los mensajes. Mira cliente-extracto.txt.

Tienes tres hallazgos del mismo servidor. Para ordenarlos, pregúntate qué hace falta para que cada uno cause daño y a cuántas personas alcanza.