Mi cookie no cambia!

vh1 · April 15, 2009, 12:17pm

Hola,
estoy utilizando restful_authentication en un proyecto. El problema es
que al hacer login 2 veces con el mismo usuario, el contenido de la
cookie que se genera es el mismo, con lo cual si algÃºn usuario
malintencionado “econtrara por casualidad” dicha cookie podrÃa operar
como usuario registrado en dicho proyecto.

He comprobado en otros proyectos y, siguiendo el mismo procedimiento, la
cookie generada es distinta, por lo que deduzco que debo tener algÃºn
error.

He buceado bastante abajo en las tripas del problema este, pero supongo
que he pasado algo por alto. Seguramente sea alguna tonterÃa pero no
samos con ella. Si alguien sabe como arreglar esto, agradezco toda la
ayuda

Gracias y un saludo

vh1 · April 15, 2009, 12:36pm

A mi me paso algo parecido, quizÃ¡ esto te ayude, pero no estoy seguro
de que sea el mismo problema por lo que comentas:

http://rails_security.lighthouseapp.com/projects/15332/tickets/40-rails-edge-and-passenger

Saludos!

vh1 · April 15, 2009, 3:18pm

Mike W. dijo [Wed, Apr 15, 2009 at 12:17:33PM +0200]:

He buceado bastante abajo en las tripas del problema este, pero supongo
que he pasado algo por alto. Seguramente sea alguna tonterÃa pero no
samos con ella. Si alguien sabe como arreglar esto, agradezco toda la
ayuda

La galleta no tiene por quÃ© cambiar, porque la sesiÃ³n subyacente no ha
cambiado - Una galleta es una identificaciÃ³n de un conjunto de
interacciones a lo largo del tiempo entre determinado navegador y
determinado cliente. La galleta es sÃ³lo la llave para una especie de
tabla (cuya implementaciÃ³n depende de cÃ³mo tienes configurada tu
aplicaciÃ³n), y los valores que le corresponden son los que cambiarÃ¡n -
La sesiÃ³n, por ejemplo, dejarÃ¡ de tener datos de determinado usuario y
tendrÃ¡ ahora los de otro cuando sales y vuelves a entrar al sistema.

Las expiraciones por inactividad (y cuestiones similares) deben ser
verificadas en tus controladores (probablemente en
application_controller), no dependas de la expiraciÃ³n de la galleta.

Respecto a tu temor de que alguien “encuentre” galletas ajenas,
tampoco es algo a lo que debes prestar demasiada atenciÃ³n - Estas son
generads por funciones criptogrÃ¡ficas Ã³ptimas para estas necesidades;
desconozco exactamente cuales, pero me aventuro a decir que es el SHA1
o MD5 de algÃºn valor aleatorio - Esto asegura un espacio de bÃºsqueda
de 2^32 (o lo que es lo mismo, de 1:4,294,967,296), con una
distribuciÃ³n homogÃ©nea e impredecible.

Saludos,

–
Gunnar W. - [email protected] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

vh1 · April 15, 2009, 5:17pm

Hola,

A mi me paso algo parecido, quizÃ¡ esto te ayude, pero no estoy seguro
de que sea el mismo problema por lo que comentas:

http://rails_security.lighthouseapp.com/projects/15332/tickets/40-rails-edge-and-passenger

Me temo que ese no es el problema que tengo. Yo puedo logearme
correctamente, pero la cookie generada para un usuario es siempre la
misma.

Gunnar W. wrote:

Las expiraciones por inactividad (y cuestiones similares) deben ser
verificadas en tus controladores (probablemente en
application_controller), no dependas de la expiraciÃ³n de la galleta.

No dependo de ella, ese es el problema. Yo hago log out, la cookie del
navegador se borra y la sesiÃ³n se resetea. Cuando vuelvo a hacer log in,
la cookie generada es idÃ©ntica.

Respecto a tu temor de que alguien “encuentre” galletas ajenas,
tampoco es algo a lo que debes prestar demasiada atenciÃ³n - Estas son
generads por funciones criptogrÃ¡ficas Ã³ptimas para estas necesidades;
desconozco exactamente cuales, pero me aventuro a decir que es el SHA1
o MD5 de algÃºn valor aleatorio - Esto asegura un espacio de bÃºsqueda
de 2^32 (o lo que es lo mismo, de 1:4,294,967,296), con una
distribuciÃ³n homogÃ©nea e impredecible.

No me preocupa que alguien se la encuentre, si no mÃ¡s bien que la
capturen y se la queden. Es un ataque bÃ¡sico que el comportamiento
normal de rails tiene solucionado, ya que la cookie generada por una
aplicaciÃ³n rails varÃa de un login a otro (excepto en el caso de mi
aplicaciÃ³n claro).

Gracias por responder Sigo buscando.

Un saludo

vh1 · April 16, 2009, 12:48am

2009/4/15 Mike W. [email protected]:

estoy utilizando restful_authentication en un proyecto. El problema es
que al hacer login 2 veces con el mismo usuario, el contenido de la
cookie que se genera es el mismo, con lo cual si algÃºn usuario
malintencionado “econtrara por casualidad” dicha cookie podrÃa operar
como usuario registrado en dicho proyecto.

Es asi, si usas el cookie store el digest es funcion de los datos y el
secret. Si te incordia el tema creo que has de cambiar de session
store.

vh1 · April 16, 2009, 8:44pm

Mike W. dijo [Wed, Apr 15, 2009 at 05:17:54PM +0200]:

Las expiraciones por inactividad (y cuestiones similares) deben ser
verificadas en tus controladores (probablemente en
application_controller), no dependas de la expiraciÃ³n de la galleta.

No dependo de ella, ese es el problema. Yo hago log out, la cookie del
navegador se borra y la sesiÃ³n se resetea. Cuando vuelvo a hacer log in,
la cookie generada es idÃ©ntica.

Ok… Vamos de nuevo sobre de ello. Â¿CÃ³mo estÃ¡s guardando las sesiones
de tu usuario? Te recomiendo fuertemente no usar directamente la
galleta (vÃa ActionController::Cookies), sino que la sesiÃ³n (vÃa el
atributo Â«sessionÂ», disponible desde tus controladores). Lo Ãºnico que
debes indicar a la sesiÃ³n es la llave con que debe identificar a su
galleta - En mi caso, tengo esto al principio de application.rb:

Pick a unique cookie name to distinguish our session data from

others’
session :session_key => ‘_comas_session_id’

Y respecto a la interacciÃ³n de galletas, no tienen nada que ver con
los datos que guardan - EntrÃ©, salÃ del sistema un par de veces. La
galleta fue invariablemente:

Cookie: lang=es; _comas_session_id=cc2195274c62855b7968d0ba5fb9d119

Desde el navegador, borrÃ© la galleta. Repito el baile, y ahora hace:

Cookie: lang=es; _comas_session_id=e615b9d4b1e72e6a933d23cb7d70e1a1

Guardo mis sesiones en la base de datos - Mi config/environment.rb
tiene:

Use the database for sessions instead of the file system

(create the session table with ‘rake db:sessions:create’)

config.action_controller.session_store = :active_record_store
config.action_controller.session = {
:session_key => “_comas_session_id”,
:secret => “9ffb62fa7055a3f4009b824be282fc38” }

Si revisas en la BD, en la tabla ‘sessions’, la galleta es el
session_id. A cada solicitud (aÃºn si es sÃ³lo un ‘reload’) se actualiza
el atributo ‘data’ - Y, claro, la longitud de ‘data’ crece conforme
hagas cosas que se guarden en la sesiÃ³n.

No me preocupa que alguien se la encuentre, si no mÃ¡s bien que la
capturen y se la queden. Es un ataque bÃ¡sico que el comportamiento
normal de rails tiene solucionado, ya que la cookie generada por una
aplicaciÃ³n rails varÃa de un login a otro (excepto en el caso de mi
aplicaciÃ³n claro).

…La galleta no tiene por quÃ© variar de un login a otro - VarÃa de un
navegador a otro. No guardas ninguna informaciÃ³n relativa al usuario
en la galleta, sino que dentro del atributo ‘data’ de la sesiÃ³n a la
que se refiere Ã©sta. Y, sÃ, si yo entro como ‘gwolf’ veinte veces
desde computadoras diferentes, las veinte veces mi galleta debe ser
distinta. Lo que tÃº notaste, claro, es digno de alarma. La galleta no
debe ser calculada en funciÃ³n de tu usuario!

Saludos,

–
Gunnar W. - [email protected] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

vh1 · April 17, 2009, 7:24pm

Xavier N. dijo [Thu, Apr 16, 2009 at 10:40:55PM +0200]:

2009/4/16 Gunnar W. [email protected]:

Y respecto a la interacciÃ³n de galletas, no tienen nada que ver con
los datos que guardan

Depende.

En este thread se asumen cookie-based sessions que es el default en
Rails recientes.

…Y ahÃ tienes datos de sobra para saber que hay situaciones en que
no es lo conveniente

–
Gunnar W. - [email protected] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

vh1 · April 22, 2009, 8:49pm

Hola, vayamos por partes:

Gunnar W. wrote:

Ok… Vamos de nuevo sobre de ello. Â¿CÃ³mo estÃ¡s guardando las sesiones
de tu usuario? Te recomiendo fuertemente no usar directamente la
galleta (vÃa ActionController::Cookies), sino que la sesiÃ³n (vÃa el
atributo Â«sessionÂ», disponible desde tus controladores). Lo Ãºnico que
debes indicar a la sesiÃ³n es la llave con que debe identificar a su
galleta - En mi caso, tengo esto al principio de application.rb:

Pick a unique cookie name to distinguish our session data from

others’
session :session_key => ‘_comas_session_id’

Estoy usando el atributo session. TambiÃ©n tengo un :session_key en
application.rb

Y respecto a la interacciÃ³n de galletas, no tienen nada que ver con
los datos que guardan - EntrÃ©, salÃ del sistema un par de veces. La
galleta fue invariablemente:

Cookie: lang=es; _comas_session_id=cc2195274c62855b7968d0ba5fb9d119

Desde el navegador, borrÃ© la galleta. Repito el baile, y ahora hace:

Cookie: lang=es; _comas_session_id=e615b9d4b1e72e6a933d23cb7d70e1a1

Guardo mis sesiones en la base de datos - Mi config/environment.rb
tiene:

Use the database for sessions instead of the file system

(create the session table with ‘rake db:sessions:create’)

config.action_controller.session_store = :active_record_store
config.action_controller.session = {
:session_key => “_comas_session_id”,
:secret => “9ffb62fa7055a3f4009b824be282fc38” }

Si revisas en la BD, en la tabla ‘sessions’, la galleta es el
session_id. A cada solicitud (aÃºn si es sÃ³lo un ‘reload’) se actualiza
el atributo ‘data’ - Y, claro, la longitud de ‘data’ crece conforme
hagas cosas que se guarden en la sesiÃ³n.

No me he explicado bien. El problema es que el atributo ‘data’ no cambia
en mi caso. Ni al hacer reload, ni al borrar la cookie y entrar de
nuevo, ni al cerrar el navegador y abrirlo de nuevo ni al cambiar de
navegador. LÃ³gicamente, si hago algÃºn cambio a mano en ‘session’
(guardar el color favorito del usuario en la session) el campo data
cambia, pero la prÃ³xima vez que haga login y guarde de nuevo el
atributo, el contenido de ‘data’ volverÃ¡ a ser el mismo que ahora.

Para mÃ¡s datos, he probado a usar tanto active_record_store (base de
datos) como la opciÃ³n por defecto.

Â¿Alguna idea?

Un saludo

vh1 · April 30, 2009, 12:59pm

Hola,
sigo peleÃ¡ndome con esto pero no llego a ninguna conclusiÃ³n vÃ¡lida, ya
que el contenido de mi cookie sigue sin cambiar. Â¿Alguna idea?

Gracias y un saludo

vh1 · April 30, 2009, 5:07pm

2009/4/30 Mike W. [email protected]:

Hola,
sigo peleÃ¡ndome con esto pero no llego a ninguna conclusiÃ³n vÃ¡lida, ya
que el contenido de mi cookie sigue sin cambiar. Â¿Alguna idea?

De este thread, si alguna cosa ha de quedar es que esto depende del
storage.

Que storage estas usando.

vh1 · April 16, 2009, 10:41pm

2009/4/16 Gunnar W. [email protected]:

Y respecto a la interacciÃ³n de galletas, no tienen nada que ver con
los datos que guardan

Depende.

En este thread se asumen cookie-based sessions que es el default en
Rails recientes.

vh1 · May 6, 2009, 10:37am

2009/5/6 Mike W. [email protected]:

Estoy usando el storage por defecto de rails (CookieStore).

Con ese storage en efecto da lo mismo, en algun mensaje explique por
que sucede asi.

ProbÃ© con ActiveRecordStore, pero mi problema seguÃa siendo el mismo.

Seguramente te liarias con la prueba. Con ese storage el cliente
recibe un session ID que se genera aleatoriamente para cada nueva
sesion.

vh1 · May 6, 2009, 9:49am

Xavier N. wrote:

2009/4/30 Mike W. [email protected]:

Hola,
sigo peleÃ¡ndome con esto pero no llego a ninguna conclusiÃ³n vÃ¡lida, ya
que el contenido de mi cookie sigue sin cambiar. Â¿Alguna idea?

De este thread, si alguna cosa ha de quedar es que esto depende del
storage.

Que storage estas usando.

Estoy usando el storage por defecto de rails (CookieStore). ProbÃ© con
ActiveRecordStore, pero mi problema seguÃa siendo el mismo.

Un saludo