Re: [PHPLIB] Session Hijacking From: Kristian Koehntopp (kris <email protected>)
Date: 03/31/00

In netuse.lists.phplib you write:
>I have a client who is querying the security of sessions. If the
>session id is passed around (GET) then it would be possible to grab it
>in the same way that clear text passwords can be grabbed as they float
>around. If someone was to get the session ID in this way then they
>could keep the session alive after the real user has finished.
>I presume that if the real user specifically logs out then the session
>ID becomes invalid. But if they don't log out then the that could be a
>problem.

Please distinguish between a session id and an authenticated
user id. A session may be in use, but not contain a user id at
all. It is just used to string together a sequence of page
accesses. It has got nothing to do with users at all, only with
the ability to remember what has happened on pages accessed
before.

A session may go through the authentication process and it may
do so sucessfully or unsucessfully. If a session manages to
authenticate itself, that is, if a session manages to get a uid
passed back from its call to $auth->auth_validatelogin(), then
the session will contain an $auth object.

That auth object contains a user id $auth->auth["uid"] and a
timeout, $auth->auth["exp"]. This is what authenticates a
session. The userid contained within the $auth object contained
within the session is different from the session id. Unlike the
session id it is never exposed to the client browser and unlike
a session id a client browser cannot manipulate the user id. The
only way to insert a user id into a session is by going
successfully through $auth->auth_validatelogin() and the only
ways to get the user id out of a session are

- automatically with $auth object timeout
- manually with $auth->logout() or $auth->unauth()

Similarly, a session id will leave the system automatically
through timeout and garbage collection or manually through
$sess->destroy().

All ids do have individual timeouts. The session id does have a
timeout in the client browser, which is the cookie lifetime,
determined with $sess->lifetime in minutes (0 is special and
default). It also does have a timeout in the session object on
the server side, which is $sess->gc_time in minutes (1440
minutes == 1 day default).

The user id does have a timeout only on the server side, as it
is never exposed to the client browser. It is determined by
$auth->timeout (15 minutes default).

Now, if somebody snoops your connections and grabs hold of a
session id, that person can use the session id to hijack the
session. If the hijacked session is not being used for
$auth->lifetime minutes, the authentication will time out and
there is no way to reauthenticate the session besides going
through $auth->auth_validatelogin(), which will require a
username and a password unless you are doing something extremely
stupid in your auth_validatelogin() function (but then, it is
not the fault of PHPLIB if you insist shooting yourself into the
foot).

The session will be kept alive, though, for a much longer time.
So if your user manages to reauthenticate himself, he will find
all his variables neatly stacked and stuffed away in the
session, just as he exspects them to be.

If your client is concerned about somebody snooping his data,
you should create a certificate and switch to SSL connections.
PHPLIB contains no mechanisms at all which can secure a
connection against snooping or against impersonation through
man-in-the-middle attacks. Such mechanisms require a public key
infrastructure and certificates and there is absolutely no use
in building a second infrastructure for this in parallel to the
already existing SSL infrastructure.

If you are running standard SSL configurations, only the server
will prove its identity with a server certificate. Client
identity is not determined with standard SSL and the user still
has to log in. Unlike unprotected communication all communication
between server and client will be encrypted, though, including
URLs. Also, since the server establishes its identity with a
certificate there is a high probability that the user is
actually talking to the real server and not an attacker.

If you are running SSL with client certificates, both parties
will have certified identities. You could easily write an
$auth->auth_validatelogin() or better an $auth->auth_preauth()
function which grabs the client cert variables from the
environment and uses them to authenticate the user. The user
will not see a login prompt at all, but will be logged in
automatically through the client certificate. An equally trivial
extension of this scheme will fall back into the usual login
prompt for all users without a client cert.

When writing web applications, please forget about the existence
of IP addresses. They bear no relation at all to anything
relevant at the application level. Putting any kind of trust
or even significance into IP addresses leads nowhere.

Please stop for a moment and think about load balancing proxy
networks or about masquerading: What machines IP number are you
seeing and what relationship will that number have to the
machine the user is on? What if the load situation changes and
the next request from the same user is shifted to another proxy
in the network?

A clients IP address may be exposed through Via or other headers
generated by the proxy: Will that IP address be unique
considering that reason to exist for many proxies are RFC
network numbers or illegal network numbers used for client IP
addresses? How many machines in this world do have the IP
address 192.168.1.1?

Consider multiuser machines with X terminals. How many users
will be accessing your server with the same IP address in such
cases even if that machine is directly connected?

Consider dialup lines. A user pauses and keeps the browser idle,
but running. The dialup line is taken down. Then the user
resumes and the line is reconnected. Will that user be assigned
the same dynamic IP address again or will the IP address change
from the servers point of view?

What if the dialup user in question is Boris Erdmann, who has a
timer driven IP network setup and whose system will switch telco
providers in such a way that the cheapest telco and internet
provider is used for each hour of the week? Such users will turn
from Mobilcom into Teldafax customers at the strike of the
clock. They will not only change their IP address, but their
autonomous system ids and traceroute pathes from one request to
another.

Now how exactly are you imagining PHPLIB should be dealing with
this other than the way it does now?

Kristian

-
PHP3 Base Library Mailing List. Send messages to <phplib <email protected>>.
To unsubscribe, send "unsubscribe" to <phplib-request <email protected>> in
the body, not the subject, of your message.