PHP sessions: suspicious session keys!

suspicious php session keys like readable words - bug?

[roMancer]

Hi all,
problem is: on our server it frequently happens that customers are able to use another customer's login to order a product (without ANY login process, as it seems).

after days of searching config files, logfiles, php code, I've found suspicious session keys in our mysql database which we use for session management:
keys should be a long, encrypted string, right?
here, we've got session keys like 'source', 'function.unlink', 'function.next', ...
...among the usual keys, and they reoccur every now and then.

now my theory is: if a user gets such a sessionkey, and another user accidentally gets the same... well.

what do you think?
any ideas?
(un)known bug?

or even known/correct behaviour, no problem, because php makes sure no different client/ip/... gets an already existing sessionkey? (in this case my search for the problem hasn't stopped yet... ;-) ...and I wonder why php would generate such weird session keys...)

any comment appreciated,
thanks in advance,
regards,
ro

[roMancer]

addendum:
machine configuration:

Linux ppv 2.6.20-gentoo-r8 #2 SMP Fri Jul 6 20:34:52 CEST 2007 x86_64 Dual Core AMD Opteron(tm) Processor 175 AuthenticAMD GNU/Linux

PHP Version => 5.2.1-pl3-gentoo

Server version: Apache/2.0.59
Server built: Feb 3 2007 11:14:56
Server's Module Magic Number: 20020903:12
Server loaded: APR 0.9.12, APR-UTIL 0.9.12
Compiled using: APR 0.9.12, APR-UTIL 0.9.12
Architecture: 64-bit

[edited by: roMancer at 7:35 pm (utc) on Nov. 6, 2008]

[jatar_k]

I think you should look at the code that writes those values to the db first

profile the data they are getting and then you can figure out where it's coming from

when I started reading your message I was thinking standard session hijacking but values such as that shouldn't be in your session id col

definitely a bug and a bad one

[roMancer]

hi,
thanks for your reply.

I think the problem has been there with PHP's default session.save_handler = files (to /tmp directory), and it's still there now with custom (session.save_handler = user) session handling using session_set_save_handler() and assigning our own functions.

now when dumping the session keys our functions receive, it's obvious there are bad ones. dumping happens before anything goes in or out of the database, right in the first line of our - e.g. - _session_write custom function.

so I'm assuming it's PHP internal, not our php-script code, right?

btw., we're talking about 'xtCommerce' opensource online shopping software. some people have reported the same problem as we have (2 users, same account), but the code looks ok, and I think there had to be more bug-reports if it was a xtCommerce-sourcecode-related problem.

[roMancer]

please, can you explain 'standard session hijacking' - how does this work?

[dreamcatcher]

A post you may find useful:
[shiflett.org...]

dc