RE: [PHPLIB] Session Hijacking From: Howard Ha (howardh <email protected>)
Date: 03/31/00

Hey that's a really good description of the flaws of IP based security and
how secure PHPLIB can be.

I just wanted to add that most sites that will implement PHPLIB should not
expect something as serious as session hijacking. You are trying to foil a
thief who should NOT be interested in your field in the first place. Take
for example most ecommerce sites such as Amazon.com, buy.com, and even
ebay - these sites do not have any sort of SSL or special protection in
place throughout the majority of the site, and yet millions of people
frequent them daily. I think for the most part: e-commerce, simple
authentication for non critical online applications, and most casual
authentication use, PHPLIB is highly secure and perhaps even more secure
than many other solutions out there (if you combine the MD5 auth class with
the MD5 javascript authentication, clear text passwords are never even
stored nor transferred except during the first transfer in the registration
stage).

This is not to say that you don't switch to a secure system once the client
is ready to pass over his credit card # or something the like. I think you
will find that a combination authentication/session tracking for the
majority of the site with a secure section just for the transaction of
purchases is the most common setup in ecommerce. If your client is thinking
of building a banking, social security, or some other serious and private
online application, he shouldn't even consider something as simple as
PHPLIB, since I doubt Kristian ever intended it for that type of uber high
security use.

The way I imagine use of PHPLIB for sessions is something as simple as
whether a user has filled out a survey in that visit, what pages he's
visited, as well as how long he's been there, etc. I doubt that there would
be great benefit in hijacking his session for some malicious intent :) Now
when you start going into authentication uses, hijacking becomes more
serious, but still... at best the hijacker can fool around for that session
alone. And if you have sufficient measures in place, he shouldn't be able
to do any serious damage. If it is that serious for you, take the following
precautions:

1) Use the MD5 auth table, and don't pass clear text passwords
2) have users re-authenticate themselves before they can manipulate or see
their personal data.
3) you can be extra strict and further ask authorisation of major changes or
information request via email verification (eg: register.com requires email
confirmation of DNS changes)
4) shorten the lifespan of each session. Make it so that a session must
re-authenticate every 2 hours or something.
5) extend PHPLIB to include a second, random value that is encrypted based
on the user's name and which has a random cookie name stored in your
session. Make it so that that early into all your pages the cookiename is
pulled from the session and the value of the cookie compared to the stored
value. The random value must match the stored value in the session or else
it will automatically either cut the session short, or ask for
re-authentication. (btw, the reason this may help is because the hijacker
may only be stealing your sess ID and may know nothing about your other
cookies).
6) store the IP of every important transaction (yes I know about all the IP
spoofing and everything), along with other HTTP given info like browser, OS,
etc (unreliable but at least it's SOME level of protection). At least this
way you can catch the lesser troublemakers who don't use fancy IP spoofing.

Howard

> -----Original Message-----
> From: phplib-owner <email protected>
> [mailto:phplib-owner <email protected>]On Behalf Of Kristian Koehntopp
> Sent: Thursday, March 30, 2000 10:43 PM
> To: phplib <email protected>
> Subject: Re: [PHPLIB] Session Hijacking
>
>
> 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.

-
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.