[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-general-es
Subject:    Re: [PHP-ES]
From:       "Manuel Oterino" <manuel.oterino () sorase ! biz>
Date:       2006-03-29 8:17:30
Message-ID: 50691.194.179.55.36.1143620250.squirrel () llca463-a ! servidoresdns ! net
[Download RAW message or body]


> ----- Original Message -----
> From: "Manuel Oterino" <manuel.oterino@sorase.biz>
>
>
>> Hola Satyam/Pablo.
>>
>>>
>>> ----- Original Message -----
>>> From: "Pablo Siciliano" <psiciliano@puentenet.com>
>>>
>>>> Hola Satyam,
>>>>
>>>> Esta vez pasarlo offlist fue de vago nomas ;)
>>>>
>>>> Te soy sincero, veía un problema de fuerza bruta, pero después al tener
>>>> que escribirlo me di cuenta de que lo estas evitando al hacer el doble
>>>> MD5: Por mas que alguien consiga una colición de que le permita obtener
>>>> algo igual a md5(md5(trim($password))+$session_id()), todavía tiene que
>>>> el
>>>> segundo md5(). Y no va a poder obtener el password teniendo una
>>>> colición.
>>>
>>> El caso es que para el segundo MD5, el interno, estoy obligado pues eso
>>> es
>>> lo que tengo almacenado en la base de datos. Siguiendo tu notación, lo
>>> que
>>> tengo en la base es:  md5(trim($password)) por lo que del lado del
>>> servidor
>>> no puedo sino concatenar el session_id con esa expresion.
>>>
>>>
>>
>> Correcto.
>>
>>>> Lo que se me ocurrió después es que de lo que te salva SSL y que tu
>>>> mecanismo no contempla, es la reactuación.
>>>> Si alguien captura post de un login válido puede reenviar un post igual,
>>>> session id incluído, y se loguea siempre y cuado la sesión sea válida.
>>>> Para eso le basta con un buen sniffer y el Paros Proxy ;)
>>>>
>>>
>>> Alguien me hizo notar eso en la lista en ingles y estaba por comentarlo
>>> en
>>> esta lista, pero tu me has ganado.
>>>
>>> En realidad, originalmente yo pensé enviar como 'desafío' un aleatorio
>>> cualquiera.  Luego vi que el session_id era bastante aleatorio y largo,
>>> cosa
>>> también importante.  El caso es que aunque el servidor le enviara al
>>> cliente
>>> un session_id, nada impide que el cliente responda con un session_id
>>> inventado en sus headers y el PHP lo acepte y calcule con él.  Si el PHP
>>> lo
>>> acepta y genera una session con ese valor o lo rechaza, eso no lo sé y
>>> bien
>>> pudiera depender de la versión de PHP con lo cual el esquema podría
>>> funcionar o no, pero no habría certeza y sería un potencial agujero de
>>> seguridad.
>>>
>>> El esquema que se me ocurrió entonces es el siguiente.
>>>
>>> En el servidor, al enviar al cliente la pagina de login, se genera un
>>> unique_id con la funcion uniqid().  Este lo almaceno en una variable de
>>> sesion.  El cliente calcula el hash con este valor, no con el de sesion.
>>> Cuando el servidor recibe la respuesta del login busca el unique_id
>>> almacenado en la sesion y hace su cálculo con este valor.  Si le hubieran
>>> enviado otro id de sesion, no encontraría el mismo unique_id o, si la
>>> sesion
>>> no existiera, no encontraría ninguno en absoluto.   Si el login falla y
>>> hay
>>> que reintentar, se deberá enviar y guardar en la sesión un nuevo
>>> unique_id
>>> aunque se mantuviera el mismo session_id.  Si el login tiene exito, se
>>> borra
>>> el unique_id de las variables de sesion.
>>>
>>
>> Correcto. Esto ya proporciona un buen nivel de seguridad, pero sigo
>> reiterandome en el
>> uso de session_regenerate_id( ).
>>
>> Es similar al planteamiento anterior con un añadido, pero lo hace
>> internamente PHP,
>> generando un id de sessión distinto entre llamadas. Esto te asegura que si
>> alguien capto
>> tu id de sessión e intenta llamarte con este, no podrá si se regenero y es
>> distinto a la
>> primera petición.
>>
>
> No creo que sea una buena idea.  Yo no sé cómo y cuando el runtime de PHP se
> deshace de las sesiones viejas.   Imagino que quedarán por ahi como zombies
> durante un tiempo hasta que pase algún recolector de basura.  Si a cada
> reintento de login generas una nueva sesion, eso quiere decir que estas
> dejando una dormida tras de ti.

Es posible que no sea buena idea, asumiendo que te van a realizar ataques para entrar o
colapsar tu sitio. Yo pienso que si lo quieren hacer, lo harán, por lo menos lo de
saturar tu servidor.
Yo nomalamente tiendo a pensar como lo hacen las base de datos, es decir, al ejecutar
sentencias SQL, por defecto deja todo preparado como si realmente se hubiera realizado y
realizar una operación de COMMIT es muy rápida, sin enbargo un ROLLBACK es muy costoso.
Esto viene por que si cada intento de acceso a tu Web (correcto o incorrecto) regeneras
la sessión solo se realiza en este punto. Si realmente te están intentado atacar, eso no
es un problema de rendimiento de tu aplicación, nos puede pasar a cualquiera. En
cualquier caso, si ves que se reiteran los intentos de acceso desde un mismo punto y ocn
intervalos pequeños, pon en tu PHP un sleep.

> Ahora, imagina que estas intentando forzar
> el login por fuerza bruta, intentando con valores al azar.   Has capturado
> un valor de sesion y estas intentando con esa.   Fallas, pero el programa te
> permite intentar de nuevo, pero esta vez con una nueva sesion y un nuevo
> unique_id.  Pero tu ignoras esa nueva sesion, pues la vieja ha quedado
> perdida por ahi y posiblemente disponible.  Intentas sobre esa sesion y con
> otro valor.  Mientras sigas intentando, el 'timeout' de la sesion no se
> vence, por lo tanto seguirá allí eternamente.   Entre tanto, a cada intento
> fallido, tu generas una nueva sesion que, en realidad, ni el intruso ni
> nadie usará y que bien pueden hacer colapsar tu servidor aunque el intruso
> no lograra acceder.


En cualqueir intento de acceso bueno o fallido, hay que borrar la sessión antigua y
regenerar la nueva. A partir de la version 5.1, session_regenerate_id tiene un parametro
para indicarle que borre la sessión, por lo que entiendo que borrará el fichero. En la
4.3.2, sería bueno realizar un session_destroy y así eliminar los ficheros.


Salu2.
>
> Satyam
>
> (el resto del mensaje ha sido truncado)
>
>


Manuel Oterino
Sorase Consultoría, S.L.

-- 
PHP Spanish Localization Talk Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]