Guía de solución de problemas de sesiones de aplicaciones autohospedadas por cambios en el proxy y las cookies

El enfoque seguro consiste en tratar una comparación capa por capa de las solicitudes directas y las solicitudes mediante proxy, las cookies de respuesta, el almacenamiento del navegador y el estado de la sesión en el backend como una secuencia de puntos de comprobación observables, no como un único comando.

En una aplicación web autoalojada detrás de un proxy inverso, el riesgo práctico es que los usuarios cierren sesión, queden atrapados en un bucle de redirecciones o no puedan establecer una sesión después de cambiar el proxy o las cookies. Registra la identidad actual y el punto de recuperación, empieza por el factor diferenciador menos invasivo, interpreta los resultados correctos y fallidos antes de cambiar otra variable y detente cuando el almacenamiento se vuelva inestable o la única copia recuperable pudiera quedar expuesta. El flujo de trabajo siguiente solo termina cuando la carga de trabajo original funciona o las pruebas alcanzan un límite que requiere escalar el problema.

Reproduce una ruta de sesión y conserva las pruebas

Elige un usuario, un perfil del navegador, un nombre de host y una ruta de inicio de sesión. Registra la primera solicitud que falla, la secuencia de estados, las ubicaciones de redirección, las cabeceras de respuesta Set-Cookie con los valores ocultos, las cookies de solicitud, los registros del proxy, los registros de la aplicación y el cambio exacto de configuración que precedió al fallo.

No empieces borrando todas las cookies ni rotando el secreto de la aplicación. Usa un perfil de navegador privado como control limpio y conserva el perfil que falla para compararlo. Confirma si el acceso directo al backend funciona; así separarás la autenticación de la aplicación del comportamiento de URL y cookies derivado del proxy.

Detente si la aplicación expone tokens en los registros, el proxy acepta cabeceras de reenvío falsificadas de clientes que no son de confianza o el inicio de sesión omite TLS. Protege las credenciales y corrige el límite de seguridad antes de continuar con la resolución funcional del problema.

Verifica el esquema, el host y la confianza en el reenvío

Compara la URL externa con lo que la aplicación cree que está usando: esquema, host, puerto, ruta base y dirección IP del cliente. Inspecciona Host, X-Forwarded-Proto o las cabeceras de reenvío estandarizadas, así como la lista de proxies de confianza de la aplicación. Un backend que considera que las solicitudes HTTPS son HTTP puede rechazar las cookies Secure o generar una redirección interminable a HTTPS.

Usa un único proxy de confianza para establecer o reemplazar las cabeceras de reenvío y configura la aplicación para confiar solo en ese salto. No añadas a ciegas valores proporcionados por el cliente. Prueba un inicio de sesión y una redirección absoluta después de cada cambio, en lugar de modificar a la vez las cabeceras del proxy y la URL base de la aplicación.

La guía de ZimaSpace sobre el diagnóstico del inicio de sesión directo y mediante proxy utiliza la misma comparación entre el acceso directo y el acceso mediante proxy después de reiniciar un proxy. Su ejemplo con Immich es más específico, pero la ruta de comprobación es aplicable: demuestra que la sesión del backend funciona y después inspecciona las cabeceras de reenvío, el enrutamiento y el estado del navegador.

Inspecciona el ámbito de las cookies y las decisiones del navegador

Comprueba el nombre de la cookie, Domain, Path, Secure, HttpOnly, SameSite, la caducidad y si existen cookies duplicadas con el mismo nombre en diferentes rutas o dominios. Las herramientas de desarrollo del navegador muestran si una cookie se almacenó, se rechazó o se omitió en la siguiente solicitud; los registros del servidor por sí solos no pueden revelar esa decisión.

El recurso de OWASP sobre el comportamiento de las cookies SameSite explica cómo los valores de SameSite controlan el envío de cookies entre sitios. Si la autenticación cruza sitios o utiliza un flujo incrustado, SameSite=None también requiere Secure; en una aplicación sencilla del mismo sitio, ampliar innecesariamente el alcance de la cookie debilita el diseño.

Borra únicamente la cookie afectada en el perfil de control después de registrarla y repite el inicio de sesión. Si una cookie nueva funciona mientras el perfil conservado falla, compara el ámbito y la caducidad; si ambos fallan, vuelve a las cabeceras de respuesta o al almacenamiento de sesiones del backend en lugar de borrar el estado repetidamente.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comprueba el estado compartido de la sesión y valida la solución

En aplicaciones con varios contenedores o replicadas, confirma que cada instancia utilice el mismo secreto para firmar sesiones, la misma fuente de tiempo y el mismo backend de sesiones compartido cuando sea necesario. Un proxy que alterna entre instancias puede parecer un cierre de sesión aleatorio cuando una instancia no puede validar la cookie de otra.

El análisis de PortSwigger sobre el límite de seguridad de SameSite se centra en la seguridad, pero aclara que SameSite es un límite del navegador, no un interruptor genérico para reparar el inicio de sesión. Conserva la protección contra CSRF mientras la ajustas al origen real de la aplicación y a su flujo de redirección.

Valida el inicio de sesión, el cierre de sesión, la caducidad por inactividad, el reinicio del navegador, el cambio de contraseña y el acceso mediante los nombres de host internos y remotos previstos. Cierra el incidente solo cuando las cookies antiguas fallen de forma segura, las sesiones nuevas sobrevivan al enrutamiento normal y ninguna cabecera de reenvío ni atributo de cookie se haya flexibilizado más allá de la necesidad documentada.