Re: session.save_path is a big security hole!

From: Date: Thu, 04 Sep 2003 17:47:28 +0000
Subject: Re: session.save_path is a big security hole!
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-161682@lists.php.net to get a copy of this message
* Thus wrote Rx (rxx@pisem.net): > Theres absolutely no control over session.save_path parameter in php. By > setting it to every directory he wants, every user can: You can set the value with php_admin_value save_path "/tmp" > > 1. (!!!) Absolutely easily generate new sessions with any content for every > site on server. prevented with open_basedir. Can you demonstrate how you expect to do this? Using open_basedir most can also resovle this issue. > 2. Delete other users sessions by setting gc to 100 and probably legal files > starting with sess_*. This might be a valid point if you also mention that if the user sets gc_maxlifetime to a value of 1 or lower than cache_expire, and the gc_probablity at 100. Although I havn't tested, and probably should be. I'm also not sure but technically gc_maxlifetime should never be lower than cache_expire, if this is the case then there no issues with setting gc_probablity to 100, cept for a bunch of overhead for the users script. > 3. Flood every http server writable directory with thousands or millions > files. Don't allow the person to create files. That is the only way to prevent a user of doing this regardless of the save_path parameter. > > session.save_path should be controlled under open_basedir variable or some > other mechanism. Perhaps a better solution would be to have a php.ini setting for disabling ini settings: disable_ini session.save_path,session.gc_maxlifetime Curt -- "I used to think I was indecisive, but now I'm not so sure."

« previous php.general (#161682) next »