Re: [Ayuda] Manejo de sesiones en PHP

[Sandino Araico Sánchez <sandino en sandino net>]

Esto me lo encontré en webappsec en securityfocus com, viene mejor explicado
cómo hacer buenas variables de sesión y cómo usar transacciones....

Subject:
         RE: Alternatives to session IDs as authenticators?
    Date:
         Wed, 24 Apr 2002 13:20:29 -1000
   From:
         "Jason Coombs" <jasonc en science org>
      To:
         "Eric Thomas" <eric en psteering com>, <webappsec en securityfocus com>

Aloha, Eric.

Session identifiers are not authentication if they are generated
according to a predictable algorithm. Consider, however, what a
user ID and password pair look like in bits. Most session IDs
have more bits than a user ID and password do. Therefore they
are more "secure" than a user ID and password, in terms of a
malicious third party attacker being able to guess or randomize
valid bits. SSL-security combined with random session identifiers
of variable length represent very good security.

One technique commonly employed to make session identifiers more
secure is to generate the random number and hash it with a secret
key and a keyed hash algorithm then attach the hash code to the
random number and call the combined bit sequence the session ID.
This way the server can validate the session ID and it is not
practical for attackers to randomize both the random number and
the keyed hash code.

Microsoft ASP.NET uses this technique in its Forms Authentication
mechanism, and .NET Passport use a similar technique. The user
sends credentials to authenticate once with the server, and from
that point forward the client sends only the authentication ticket
assigned to it following authentication of the credentials. The
ticket is not a simple random number, it includes a keyed hash
that only the server can verify because only it knows the secret
key used when applying the keyed hash algorithm -- only the server
can rehash the random number provided in the ticket to confirm
the authenticity of the hash provided in the ticket.

When SSL is not used, there are known problems with proxy cache
where multiple clients receive the same session IDs by way of
either cookies or URL-encoding, and man in the middle attacks
succeed in compromising session IDs because they are sent as
plaintext to and from the server. HTTP authentication must be
used, either basic or digest, with unencrypted HTTP sessions
because there is no way for the server to generate a session
ID and deliver it securely to the client such that it can be
relied upon as a shared secret -- the client must supply valid
credentials with every HTTP request, and those credentials are
used as the shared secret. Anything the server sends back to
the client without encryption is no longer a shared secret.

As for replay attacks when SSL is not used, the only defense
against such attacks is session ID expiration. As long as the
server believes the session identifier or authentication
ticket to be valid, the replay attack succeeds. You can SSL
secure the authentication event where credentials are sent
by the client to the server, but if you intend to allow the
client to browse without SSL, the authentication ticket will
have to be sent in the clear with each request and replay
attacks become possible. Cookies are marked as either SSL
secured or not, and those that are don't get sent in client
requests that aren't, so dropping a cookie after an SSL
secured authentication event that is marked secure isn't
enough, you must also direct the client to an http URL
where another cookie gets dropped.

NET Passport implements such a dual-cookie system for sites
that require SSL-secured credential transport but that need
to allow browsing with the authentication ticket to http
URLs as well. Both .NET Passport and ASP.NET Forms
Authentication expire authentication tickets and replace
them periodically. The user automatically receives the new
ticket and stops sending the old one.

Aloha & Mahalo,

Jason Coombs
jasonc en science org

MiG wrote:

> Hola a todos ¡
>
> Quisiera pedirles su opinion respecto a las sesiones en php, ¿Que tan
> seguras son?, he leido en algunas partes que no son tan seguras y son
> muy explotables. Y si alguien tiene una liga por ahi de como funcionan
> (no como usarlas, sino como trabajan) se lo agradeceria mucho.
>
> Seguimos por aki ...
>
> _______________________________________________
> Ayuda mailing list
> Ayuda en linux org mx
> Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/

--
Sandino Araico Sánchez
- Piensa en grande
- Comienza en pequeño
- Escala rápido



_______________________________________________
Ayuda mailing list
Ayuda en linux org mx
Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/