Hi, On Mon, 26 Jul 2004 10:39:42 +0200 Jakub Vrana <[EMAIL PROTECTED]> wrote:
> > Is there any way restricting people from retrieving file names (where > > open_basedir and safe_mode obviously won't help), besides adding glob to > > disable_functions in php.ini? > If I understand you correctly, only files owned by script owner (thus > potentially Apache user) are disclosed. If using safe_mode, we can get all files using glob() if the first file is owned by ourself. It's important to remember, though, that it's pretty easy to create a file with the same permission as the Apache-user (create a folder with chmod 0777 and use PHP to copy a file into that folder - the new file is owned by the Apache-user and has the same UID as e.g. the session-files. But even when using open_basedir, the warning still reveals the first filename, and by refining our glob-string ("/tmp/a*", "/tmp/b*","/tmp/ba*"), we would be able to figure out names og files and directories using a realistic small effort (as opposed to brute force). Using a little effort, we could find almost any dir/filename in the system (of course, requiring that the Apache user has access to the folder), even under safe_mode, even under open_basedir, even without performing the "Copy files to be owned by Apache-user"-trick. > Because sessions in common directory are not secure independently > whether you can read the session filenames or not (you can reveal it > from some logs), it's better to store session files in different > directories for each virtual host. I agree - or any other kind of mechanism to separate session files for virtual host. Though, these directories should not be owned by the Apache user. /tmp/ is owned by root, meaning that opendir() in safe_mode wouldn't work for retrieving all file names in /tmp/ - if /tmp/session_files/domain1.tld/ is owned by the Apache-user, we would be able to use opendir() to retrieve all file names. Again, I think glob() in safe_mode should perform a UID-check for the directory, not (directory || first_matched_file). I would hope that some kind of general default-mechanism would be implemented, instead of requiring the administrator to put up custom save_path's for each virtual host. With the popularity of PHP, I don't think it's an assumption we can rely on. > This way, user can read other user's session filenames but she can't use > it for anything. Well, he won't be able to read or alter the content of the session file. But if the folder names are revealing the name of the site (like /vhost/www.company.tld/tmp/session-files/ - remember we are currently able to retrieve the file names due to glob()'s nature), he would still be able to hijack other users' sessions for that host! The result would be more random as he has no influence of the content of the session. > We use it on my company's hosting and I believe it's secure enough. .. if you don't mind your customers being able to hijack other customers' users' sessions :) I really would like both glob() and session storage to behave in a different way per default, though it might be two different cases. But currently, even: - with safe_mode-restriction - with open_basedir-restriction - with custom session.save_path for each virtual host/user - without allowing php-scripts of the same UID as the Apache user to be executed (mostly because of the possibility of bypassing a safe_mode-UID-check) .. a user on the hosting server would still be able to figure out session names for sessions on another host on the same server, and would be able to hijack those sessions. Even when taking all measures that PHP offers, there still is a issue with session hijacking! > P.S. I'm on your side with securing glob() but it will not solve all > security risks with session files stored in common directory. Thanks - and I agree, though if glob() was fixed (no disclosure in warnings and only check UID for directory), safe_mode might actually be enough to prevent session file names being revealed. A user could still alter his own session file, though. If it isn't possible to hide the file names, another solution might be to store a hash (e.g. md5) of the session id instead of the name of the session id itself, as PHP always goes from user data to session file, and not the other way around. For a user with the session name "deadbeefdeadbeefdeadbeefdeadbeef", data could be stored in sess_(md5sum of "deadbeefdeadbeefdeadbeefdeadbeef"). That way, gaining access to the file name of a session file wouldn't allow you to hijack that session, since you wouldn't have the original session name (but only the hashed value). -- - Peter Brodersen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php