Fallos de OAuth y de sesiones: cómo se roban cuentas

Qué es

Esta categoría reúne los fallos en cómo una aplicación crea, guarda y delega sesiones. Dos familias aparecen una y otra vez:

• OAuth y "inicia sesión con…": el flujo por el que otra web (Google, GitHub, la propia empresa) te identifica y devuelve un código o un token a la aplicación. Si la aplicación valida mal a dónde se envía ese código, un atacante puede quedárselo y entrar en tu cuenta.
• Gestión de sesiones: tokens que no caducan, sesiones que siguen vivas tras cambiar la contraseña o cerrar sesión, cookies sin las protecciones adecuadas o identificadores de sesión predecibles.

Dónde suele aparecer

• El parámetro redirect_uri, cuando el servidor acepta variaciones de la dirección registrada (subdominios, rutas o parámetros añadidos) o una redirección abierta dentro del dominio permitido.
• El parámetro state ausente o sin comprobar, que permite vincular tu cuenta a la del atacante (un CSRF en el inicio de sesión).
• Tokens en la URL que se filtran por la cabecera Referer, el historial o los registros.
• Vinculación de cuentas sociales a una cuenta existente sin confirmar el correo.
• Cierre de sesión que solo borra la cookie en el navegador pero no invalida la sesión en el servidor.

Cómo se busca

1. Recorre el flujo OAuth completo con un proxy y anota cada parámetro: client_id, redirect_uri, state, response_type, code.
2. Modifica redirect_uri poco a poco (otra ruta, otro subdominio, un parámetro extra) y comprueba qué acepta el servidor.
3. Quita o reutiliza state y mira si el flujo sigue funcionando.
4. Para las sesiones: copia el token, cierra sesión o cambia la contraseña, y prueba si el token antiguo sigue sirviendo.

Cómo se evita

• Comparar redirect_uri de forma exacta con la lista registrada.
• Exigir y comprobar state (y usar PKCE, recomendado hoy en todos los clientes).
• Códigos de autorización de un solo uso y de vida corta.
• Invalidar en el servidor todas las sesiones al cambiar la contraseña o cerrar sesión, y cookies con Secure, HttpOnly y SameSite.

Al reportarlo

Muestra la cadena completa con tus propias cuentas: desde el enlace que recibiría la víctima hasta el acceso a su sesión. En OAuth el impacto suele ser la toma de cuenta, y conviene demostrarlo de principio a fin.