[Note: safely skip the descriptive part and go directly to the tool if you already know how PHP does session handling.] Sessions are a great feature as they allow developers to store sensitive data for a limited amount of time (the session lifetime) without having to ping-pong the whole dataset to and from the client. A session mechanism can be implemented at the "user" level in the application code but most of the languages used to develop web applications provide various build-ins to accomplish the task. This is the case of PHP and its famous "session" module (Session Support in phpinfo()). The $_SESSION array can be used transparently and the session has just to be started with session_start() (or even automatically started at the configuration level with session.auto_start).
Authentication "tokens", passwords and sensitive data can be stored into $_SESSION as the session will be accessible only from the interpreter on the server side. Such data will be persistent across pages and is just identified by a session token (normally PHPSESS_%{MD5}), also called session ID, that is transmitted from the client as a Cookie value.
PHP has different ways to effectively store the session, known as Save Handlers. The sysadmin can choose one of the installed handlers at the configuration level using the session.save_handler key. Individual extensions may register their own save_handlers. Registered save handlers can be "files", "user", "sqlite", "memcache" and common registered serializer handlers are "php", "php_binary", "wddx". While the first group decides where and how to store the data, the second one decides how to create a representation of the data.
Custom "user-level" handlers can also be specified using session_set_save_handler() and the needed callback functions. This article and the released tool focus on the default configuration and doesn't apply to any other combination.
PHP and vendors ship a php.ini with session.save_handler set to "file" and session.serialize_handler set to "php", which is also the most common deploy on tuned setups. This alone doesn't constitute a security risk but often administrators forget to set a different session.save_path for each vhost resulting in session files stored in /tmp and being readable by virtually everything running locally on the server. Ths includes every single application on every domain hosted and naturally special crafted code loaded on purpose on the server.
Now, after this short excursus about a well known issue, I'm glad to release a simple script particularly useful on shared hosting/mass virtual hosting servers: it dumps configuration settings, users, groups and session files using both raw and "decode" (using session_decode()) methods. Everything in a greppable/regexp-friendly format.
http://www_ush_it/team/ascii/hack-sessiondumper/sessiondumper-0.1.php
This article can be viewed in text version at the url:
http://www_ush_it/team/ascii/hack-sessiondumper/session_dumper.txt