Aplicación web - Vencimiento de la cookie

Question

Aplicación web - Vencimiento de la cookie

#1 de Dinu S (5 votos)
#2 de Thomas Pornin (4 votos)
#3 de AJ Henderson (0 votos)

1

Estamos utilizando una aplicación web en la nube. Necesito una pequeña aclaración. Estamos utilizando Perl con Apache. Veo un problema siguiente aquí para el siguiente escenario. Necesito algunos comentarios sobre si esto es más vulnerable o no. Escenario:

Login user to webapp.
remember the home page URL post login.
process: cookie gets set along with value.
save the cookie and the value.

Logout from web browser.
create the same cookie with the same value before logout.
hit the home url.
it bypasses the authentication mode.

La cookie caduca a los 20 minutos.

El factor más preocupante es que, incluso cuando transfiero la cookie a otro navegador e intento acceder a la URL de inicio de sesión, la autenticación se omite.

Me gustaría saber qué tan vulnerable es esto y qué tan grave es si es más vulnerable.

web-application apache cookies perl

pregunta srini 04.01.2013 - 13:08

fuente

3 respuestas

Lea otras preguntas en las etiquetas web-application apache cookies perl

¿Este enfoque de protección de cookies es seguro? Limpiar completamente un disco duro (es decir, nada es recuperable) [duplicado]

score 5 · Answer 1

Hay muchas formas en las que un mecanismo de administración de sesión puede fallar y esto podría generar graves riesgos de seguridad.

Como buena práctica debes:

Use HTTPS, para que la información en las cookies no pueda ser interceptada en tránsito.
Establezca la marca de seguridad para las cookies, para que no se envíen a través de conexiones no cifradas.
Establezca la marca HTTPOnly para las cookies, de modo que no puedan leerse con JavaScript
Asegúrese de que el identificador de sesión (el valor en la cookie que identifica una sesión de usuario válida) no sea fácil de predecir. Utilice cadenas aleatorias grandes para este propósito.
Asegúrese de que el identificador de la sesión se modifique cuando el usuario inicie una nueva sesión (inicie sesión) para evitar la fijación de la sesión
Se debe implementar un mecanismo de expiración de sesión en el servidor. No confíe en el usuario para este trabajo.
Cuando el usuario cierre la sesión, invalide la sesión en el servidor, de modo que incluso si un atacante intenta usar el identificador, el servidor no lo aceptará.

Desde su descripción, su aplicación no cumple con el último punto de la lista anterior. Debe comprobar si los otros puntos están satisfechos. La suma de todas las vulnerabilidades en la aplicación es la que te ofrece una visión general de lo seguro / vulnerable que eres.

Debe tener en cuenta que al explotar el problema que ha descrito, uno puede tener acceso a una cuenta de usuario sin credenciales. ¿Qué tan malo es esto en el contexto de su aplicación? ¿Podría este usuario malintencionado acceder a datos confidenciales, realizar pedidos, etc.? Para una aplicación, esto puede tener un gran impacto, para otra puede ser menos importante.

Para más información, echa un vistazo a: Hoja informativa de gestión de sesiones de OWASP

score 4 · Answer 2

Necesitas memoria . Si el servidor no recuerda quiénes son los clientes y cuándo se autenticaron por última vez, y en su lugar confía en los clientes para mantenerse al día, entonces los clientes están en posición de engañar al servidor. Lo que usted describe (guardar y luego restablecer la cookie) se llama, en general, un ataque de repetición . Para ver las cosas conceptualmente, con la caducidad de las cookies, está esperando que el atacante potencial sea lo suficientemente elegante como para olvidar algunos datos confidenciales, donde no olvidarlo implicaría cierta ganancia para el atacante.

Esto conduce a dos formas principales de evitar el problema:

Haga que el servidor recuerde la hora de la última autenticación de cada usuario y haga cumplir la caducidad, independientemente de si el navegador del cliente expiró la cookie o no.
Codifique en la cookie la fecha de caducidad, para que el servidor pueda verificarla. Esto está descargando la memoria del servidor en los clientes; para hacerlo seguro (debido a que el cliente podría modificar sus cookies para prolongar la duración de su sesión), entonces necesita algo de criptografía, es decir, agregar un MAC computado con una clave secreta que el servidor conoce pero no le dice a nadie (en particular, los clientes no lo saben).

Dado que la criptografía está llena de trampas letales, se recomienda que aplique el primer tipo de solución. Esto es principalmente una cuestión de agregar una columna en su tabla de usuarios, en su base de datos (supongo que tiene una base de datos en el servidor); esto será barato.

La caducidad de las cookies no es confiable, incluso en contextos no hostiles, porque algunos usuarios no configuran correctamente el reloj de su computadora. Algunos están apagados por varias horas (por ejemplo, están en la zona horaria incorrecta), y algunos están apagados por varios años (simplemente no les importa).

score 0 · Answer 3

Como mínimo, las cookies deben hacer un seguimiento de dónde se estaba conectando el usuario y anular su sesión (es decir, el registro de la sesión debe estar caducado en la base de datos). Lo ideal sería utilizar HTTPS para proteger la cookie en tránsito, pero si la seguridad no es tan importante en general para el sitio, el vencimiento de la sesión de cookies después de un límite de tiempo y el cierre de sesión y la limitación a una IP determinada hará un trabajo mínimo de Evitar el abuso casual en la forma en que lo describió No impedirá que un Man in the Middle pueda secuestrar la sesión si pueden evitar el cierre de sesión o hacer cosas mientras el usuario está conectado, pero al menos lo limitaría a ataques MITM como opuestos a cualquier persona mayor que obtenga (o adivine) la cookie. Además, si está eligiendo sus propias claves de sesión, asegúrese de que sean grandes y aleatorias para no ser simplemente adivinadas.

Debo reiterar que la mejor práctica es HTTPS para todos los intercambios de credenciales, incluidas las cookies de sesión, pero también quería ofrecer un enfoque que sea mejor si no tiene HTTPS como opción.