WebApp Sec mailing list archives

RE: PHP session management


From: Tyler Larson <noreply () tlarson com>
Date: Mon, 27 Oct 2003 10:22:16 -0600

--On 10/25/2003 Gavin Zuchlinski Wrote------------------------------

Hi,
I noticed on a server how PHP creates files in /tmp in the form 
sess_XXXXXXXXX 
to store session information (of course only readable by the apache user), 
but "XXXXXXXXX" is the actual session ID. If a person has a local access to a 
system using PHP's session management, aren't they able to hijack any 
session? Am I a complete moron and am missing something?
And that aside, are there any other known problems with using PHP sessions 
(besides all the standard PHP security issues like variable access)?

-Gavin
http://libox.net/

--------------------------------------------------------------------

The whole idea of sessions is that variables are stored locally on the server 
rather than in hidden form elements, cookies, or otherwise within the network 
transmissions. It's widely agreed that this method is much more secure than 
the alternative. However, the question remains: what if an attacker has 
physical access to the server?

PHP allows you to specify where it stores session data. Storing the data in 
the /tmp directory is the default, though definately not the most secure 
option. You can create a more locked-down directory on the local disk, or use 
a database if you like. See http://www.php.net/manual/en/ref.session.php for 
details.

However you set it up, though, you're still left with the problem of what to 
do when an attacker has physical access to the session data. The common 
assumption is that if an attacker has that level of access to your server, 
session data is the least of your worries: you have a much bigger problem at 
hand. Such an attacker could, in almost ever case, completely circumvent your 
web application and its security measures, and directly modify or view the 
underlying database, programs, etc., and probably even modify your web 
application.

So, secure your servers, and don't give untrusted users access to sensitive 
data.


Current thread: