google chrome - google - Las cookies de Chrome no funcionan después de que el servidor web Tomcat se reinicie

cookies auto delete

Question

Recientemente noté que cuando reinicio mi servidor web Tomcat, el navegador Chrome ya no puede almacenar cookies. es decir, tomcat usa cookies para sesiones http, y el navegador ya no puede obtener su sesión http, también falla la cookie que usamos para almacenar el usuario conectado y el usuario no permanece conectado.

Esto parece ser un problema nuevo con Chrome, tal vez de una actualización reciente, no recuerdo haberlo visto antes. Si cierro el navegador Chrome, luego lo vuelvo a abrir, está bien de nuevo (hasta que el servidor se reinicie nuevamente).

El problema no ocurre en Firefox, parece un error en Chrome.

¿Alguien más ha notado este problema o conoce una solución?

Encontré algunas publicaciones sobre problemas de cookies de Chrome / tomcat y la sugerencia de establecer, sessionCookiePathUsesTrailingSlash = false en el contexto.xml pero esto no soluciona el problema.

Parece que podría estar relacionado con el sitio web compatible con https y http, y al cambiar entre los dos (aunque sí ocurrió en un sitio web que tampoco era compatible con https ...)

De acuerdo, ahora puedo recrear el problema, los pasos son.

1. conectarse al sitio web a través de https
2. logout / login
3. conectarse al sitio web a través de http
4. La cookie JSESSIONID de Tomcat ya no se puede almacenar (se almacenan extrañamente las cookies de usuario / contraseña)

Esto solo ocurre en Chrome, y solo desde la actualización de Chrome que agrega el indicador "inseguro" en las páginas de inicio de sesión que usan http

De acuerdo, agregué esto a mi web.xml

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Esto no solucionó el problema, pero hizo que el problema siempre se produjera a través de http, es decir, que http no pudiese almacenar la cookie JSESSIONID. Intenté <secure>false</secure> pero todavía tengo el problema anterior. Por lo tanto, está relacionado con esta configuración al menos. ¿Alguien tiene alguna idea?

Error registrado en Chrome, https://bugs.chromium.org/p/chromium/issues/detail?id=698741

Answer 1

Recuerdo haber visto esto un par de veces y, por lo que puedo recordar, esta fue la única recomendación al respecto, como mencionaste:

Una posible solución a esto podría ser agregar sessionCookiePathUsesTrailingSlash=false en el context.xml y ver cómo funciona.

Algo de información sobre el asunto de aquí

Una discusión aquí (misma solución)

Espero no confundir los problemas y esto te ayuda, házmelo saber con un comentario si necesito editar / si funcionó / ​​si debería eliminar, ¡gracias!

Answer 2

Existe un borrador para desaprobar la modificación de cookies "seguras" de orígenes no seguros (enviadas por Google). Especifica las recomendaciones para modificar el documento del Mecanismo de gestión del estado de HTTP .

Resumen del documento:

Este documento actualiza RFC6265 al eliminar la capacidad de un no
origen seguro para establecer cookies con un indicador ''seguro'' y sobrescribir
cookies cuya bandera ''segura'' está configurada. Esta depreciación mejora la
aislamiento entre orígenes HTTP y HTTPS, y reduce el riesgo de
interferencia maliciosa

Chrome ya implementó esta función en v52 y la misma función también se implementó en Mozilla hace unos días.

Para resolver este problema, creo que debe conectarse al sitio web a través de https solamente.

Answer 3

Pude reproducir su problema con Chrome: solo es necesario para crear HttpSession desde la zona HTTPS. Cualquier solicitud HTTP posterior no enviará la cookie de sesión y cualquier intento de Set-Cookie:JSESSIONID= través de HTTP es ignorado por chrome.

El problema se localiza cuando el usuario cambia de HTTPS a HTTP. La cookie de sesión HTTPS se mantiene incluso si el servidor se reinicia y funciona correctamente. (Probé con Tomcat6, Tomcat 9 y usando un proxy Apache para SSL)

Este es el encabezado de respuesta enviado por Tomcat cuando la sesión se crea desde HTTPS

 Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

y este para HTTP (nota Secure falta)

 Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

Chrome ignora el segundo set-Cookie . Por otro lado Firefox y Edge reemplazan la cookie Secure con la no secured . Para determinar cuál debe ser el comportamiento correcto, he revisado RFC2109

4.3.3 Gestión de cookies

Si un agente de usuario recibe un encabezado de respuesta Set-Cookie cuyo NAME es el mismo que una cookie preexistente, y cuyos valores de atributo de dominio y ruta coinciden exactamente (cadena) con los de una cookie preexistente, la nueva cookie reemplaza la antigua.

Por lo tanto, está claro que es un error de Chrome, como suponía en la pregunta: la cookie HTTP debe reemplazar a la establecida por HTTPS

Eliminar cookies manualmente de Chrome o invalidar la sesión en el servidor hace que funcione nuevamente (si después de estas acciones la sesión se crea usando HTTP)

De forma predeterminada, la cookie JSESSIONID se crea con Secure cuando se solicita desde HTTPS. Supongo que esta es la razón por la que Chrome no permite sobrescribir la cookie. Pero si intentas configurar <secure>false</secure> en web.xml Tomcat lo ignora y el encabezado Set-Cookie se envía con Secure

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

Cambiar el nombre de la cookie, configurar sessionCookiePathUsesTrailingSlash o eliminar HttpOnly ha tenido ningún efecto

No pude encontrar una solución alternativa para este problema, excepto la invalidación de la sesión del servidor cuando el usuario registrado cambia de HTTPS a HTTP.

Finalmente abrí un error en cromo: https://bugs.chromium.org/p/chromium/issues/detail?id=698839

ACTUALIZADO El problema finalmente se marca como No se Corrige porque es un cambio intencional. Ver https://www.chromestatus.com/feature/4506322921848832

Estrictas cookies seguras

Esto agrega restricciones a las cookies marcadas con el atributo ''Seguro''. Actualmente, no se puede acceder a las cookies seguras por orígenes inseguros (por ejemplo, HTTP). Sin embargo, los orígenes inseguros aún pueden agregar cookies seguras, eliminarlas o desalojarlas indirectamente. Esta función modifica el contenedor de cookies para que los orígenes inseguros no puedan tocar de ninguna manera las cookies seguras. Esto deja un margen para el desalojo de cookies, que aún puede causar la eliminación de cookies seguras, pero solo después de que se desalojen todas las cookies no seguras.