views:

1109

answers:

5

This article states that

If your site is run on a shared Web server, be aware that any session variables can easily be viewed by any other users on the same server.

On a larger host like GoDaddy, are there really no protections in place against this? Could it really be that easy? If it is that easy, where are the session vars of the other users on my host so I can check them out?

Edit: I didn't believe it, but here's my little program which shows that this is true! I wonder if those are really the same as the value stored in the cookies on the users' machine?

+2  A: 

The session files by default are stored in the location given by the session.save_path in php.ini. While this can be defined separately for each vhost, the files have to be readable by the httpd process, and so if you know the location, your script could read the session files from another vhost.

You could store your sessions in a database (for example, using ADODb), assuming other users of the server can't read your PHP sources to learn your db credentials!

Paul Dixon
So I cannot use one of my own directories for the session.save_path?
Yar
You can, but they would still be readable by a rogue script on the server, if it knew where to look.
Paul Dixon
+6  A: 

It is ridiculously easy because by default php.ini#session.save_path points to /tmp on Linux installs and similar for Windows. This is bad because most users have read and write privileges to /tmp because they need them. You can protect against this by storing your sesion state in the database or by changing were your PHP application stores it's session files, using session_save_path

Samuel
But I can't use one of my own private directories, right, since the httpd process needs to get at it?
Yar
You could store in a directory under your public directory (hidden with .htaccess or other) and use that. But it would only obscure your store, not prevent access.
Samuel
@Samuel, why would this not prevent access?
Yar
Because the session directory has to be readable and writable to the process which is running PHP. If you put it in your own directory, you only hide where the session store is, not disable PHP from reading it because it needs to read it for your website to work.
Samuel
+1  A: 

If you're using PHP and worried about session hijacking, check out session_regenerate_id (Link to Manual).

This won't solve the problem of the session_save paths being public as mentioned by others here, but it should prevent 99.999% of hijacking attmepts.

Mike B
What's the point? Regenerate on every web hit?
Yar
It makes the session_id a moving target, making it much harder for someone to hijack it. If someone else were to guess what the ID was, it would be lost once the original user went to another page and received a new id.
Mike B
youre mixing up clientside session hijacking and server side session hijacking- two completely different hings
Shawn Simon
A: 

use session.save_path to set, save, and handle your visitors sessions only within your account space whenever you are on a shard host.

then no one but you and your hosts employees with directory access can access them.

NEVER rely on default session handlers/location on a shared host!

<?php

        $handle = opendir(session_save_path());
        if ($handle == false)
            {
                return -1;
            }
        while (($file = readdir($handle)) !== false)
            {
                echo session_save_path() . '/' . $file .':<BR />';
                if (ereg("^sess", $file))
                    {
                        $file_array = file(session_save_path() . '/' . $file);
                        foreach ($file_array as $this_line)
                            {
                                echo $this_line."<BR />";
                            }
                echo '<BR /><BR />';

                    }
            }
        closedir($handle);

?>
Thanks for that. That helps, even though GoDaddy or whomever should do that for me.
Yar
+1  A: 

I suggesst you to store session data in DB to avoid these problems, it has the additional benefit to ease accesss live information from user's sessions.

Benoit
You mean handle the cookie and pickup from the DB using code I've written?
Yar
You can either write your own session system (manage sessions IDS, cookies, session lifecycle, etc.).Or rely on PHP ability to overload session handler functions with session_set_save_handler ( http://fr.php.net/manual/en/function.session-set-save-handler.php ), there are numerours useful comments on this page and an example with a DB backend
Benoit