Re: session.save_path is a big security hole!
| From: | Curt Zirzow | 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."