Galletas asegurar y Sesiones

El problema que estoy teniendo, que puede no ser solucionable, es el siguiente:Galletas asegurar y Sesiones

Tengo un cliente que es una gran organización de 1.500 + usuarios a los 7-8 lugares diferentes. La aplicación es una creación de aplicación PHP en el marco Kohana v3.0. La organización se encuentra detrás de un servidor proxy de filtrado en el nivel del ISP. Cada ubicación tiene una dirección IP pública principal que se canaliza a través del proxy y luego a la web. Cada usuario tiene una estación de trabajo Mac o Windows emitida por el empleador.

Lo que están experimentando parece ser colisiones de cookies. Ejemplo: un usuario inicia sesión en su estación de trabajo y luego otro usuario inicia sesión desde la misma ubicación, diferente estación de trabajo, con el mismo sistema operativo y tipo de navegador. El segundo usuario recibe la sesión activa de los primeros usuarios al recibir una cookie recién generada (token) que coincide con el primer usuario. Esto parece estar relacionado solo con la cookie 'authautologin' (establecida cuando la casilla de verificación recordarme está activada en la pantalla de inicio de sesión), pero mantengo mis opciones abiertas para el almacenamiento en caché desde el proxy (no puedo probar que el proxy aún está almacenando en caché).

Debido a la configuración de la red, el servidor ve cientos de usuarios que inician sesión desde la misma dirección IP con el mismo agente de usuario. Mi idea inicial es que la forma en que Kohana v3 genera cookies que son exclusivas del navegador (agente de usuario) no es lo suficientemente exclusiva para esta aplicación en el mundo real.

¿Alguien ha experimentado algo como esto? ¿Y cuáles serían las acciones adecuadas para tomar en la generación de cookies y sesiones? ¿Sería mejor administrar las cookies y las sesiones activas en la base de datos?

Módulos Kohana: Jelly-Auth, jalea, y de Auth
Servidor: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1 + lenny8 con Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g
navegadores conocidos: IE 8 & 9, Firefox (OS y Gana) y Safari (OS)

Fuente

2011-12-19 ixasilent

+1: Pregunta detenida - con buen detalle disponible. Bien hecho. –

Acepto, pero ¿no es esto un problema con el proxy que se aplicaría a cualquier servicio que utiliza una cookie de inicio de sesión automático? –

@Pekka que ha sido mi pensamiento/frustración durante la última semana. Luego, después de preguntarle al personal interno de TI, me enteré de que el propósito del filtro proxy era bloquear sitios como GMail, Facebook, Twitter, etc. Así que me hacen creer que no tienen acceso a sitios fuera del red donde inician sesión. Esta aplicación puede ser la única en la que se les puede emitir una cookie de inicio de sesión automático que está fuera de la red. – ixasilent

Es solo una idea pero existe/solía ser (dependiendo de su versión de Debian y PHP) un error con las sesiones de PHP.Lo que sugiero que pruebe:

Comprobar this link - esto puede no estar relacionado con su problema, pero vale la pena intentarlo
Cambiar al controlador de base de datos - que le daría un 90% de probabilidad de que esto va a arreglar todo
prueba en diferentes entonces el servidor Debian - esto puede no ser fácil de lograr, aunque

Fuente

2011-12-19 18:14:48 matino

No creo que el enlace sea aplicable, pero debidamente anotado para referencia futura. La aplicación utiliza MySQL PDO a través de los módulos Kohana 3.0 Database y Jelly. ¿Algún otro conductor en mente? Existen otros 15 sitios idénticos (el contenido de la base de datos) en este servidor para otros clientes que no informan sobre este problema, por lo que estoy bastante seguro de que tiene que ver con la composición de la red y la necesidad de corregir sintonizar la generación de cookies para este sitio. Buen enlace! Lo marcaré, ya que podría abordar un problema de tiempo de espera de la sesión con un wiki que ha estado en mi memoria durante un mes. – ixasilent

Quise decir cambiar al controlador de la base de datos de sesión, no renunciar a PDO/Jelly si eso es lo que pensaba;) – matino

tiene razón al almacenar la sesión en la base de datos corrige esto. Para ser sincero, no estoy contento con esta solución, pero la disfrutaré como un truco por ahora. Por supuesto, cuando miles de usuarios comienzan a usar la aplicación de nuevo y termino pareciendo un tonto ... ¡volveré! Solo para estar seguro, volveré a escribir el método de configuración de la clase kohana_cookie para que sea compatible con RFC 2109. Eso es al menos lo responsable de hacer. Gracias! – ixasilent

Wow thats una vulnerabilidad desagradable, ¡buena atrapada!

De lejos, la mejor manera de generar cookies en PHP es dejar que PHP lo haga: session_start(). ¡Y eso es todo! Si está generando su propia cookie, entonces realmente la arruinó en alguna parte. Ahora puede usar el $_SESSION[] super global. La mejor práctica es llamar al session_start() en un archivo de encabezado común antes de acceder a $ _SESSION en su aplicación.

Probablemente haya otros problemas que debe tener en cuenta como owasp a9, csrf y las banderas de cookies: HTTP_Only, y la marca "segura" (forzando la cookie sobre https).

Fuente

2011-12-19 16:51:16 rook

@Rock gracias! He buscado el código un par de veces y puedo verificar que sí, estoy utilizando PHP para administrar las sesiones (session_start(), session_name(), session_set_cookie_params(), session_destroy(), etc ...). Pero solo porque lo mencionaste iré a cavar de nuevo, verificará de nuevo, y daré crédito a dónde está el crédito cuando salga a tomar aire. Es un sitio SSL y se configuran los indicadores seguros y HTTP_ONLY. – ixasilent

Lo sentimos, @Rook no quiso fingir tu nombre allí. – ixasilent

@ixasilent Nunca debería necesitar establecer un valor de cookie. Creo que confía en la clase kohana_cookie para identificar a un usuario. Esto está usando setcookie(), que es malo. – rook

no estoy seguro de si he entendido bien, pero ... he entendido que la solicitud es la siguiente:

usuario (estación de trabajo) ==> proxy() ==> internet ==> sitio web de la compañía (y respuesta en dirección inversa).

Compruebe si el proxy establece "HTTP_X_FORWARDED_FOR" (en la variable superglobal $ _SERVER). Podría ser la única forma de determinar la dirección IP de la estación de trabajo del usuario. Si es así, has terminado.

Fuente

2011-12-27 21:30:07

Cerrar, pero dado que el proxy también sirve como ISP, no hay un HTTP_X_FORWARDED_FOR. – ixasilent

Respuesta

Cuestiones relacionadas