3

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?

ldav1s
  • 15,885
  • 2
  • 53
  • 56
Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421
  • I doubt you need to worry about GoDaddy allowing others to "easily view session variables" for sessions they down own. Maybe I'm just naive :) – Sampson Jan 28 '09 at 14:59
  • Then you would be quite naive, the only way to prevent it would be one web server per customer, and that would unfeasible for shared hosting. – Samuel Jan 28 '09 at 15:01
  • Perhaps I am naive. We've always got room to grow. – Sampson Jan 28 '09 at 15:16
  • My point was that I don't think the OP needs to worry about anybody publishing a list of active sessions for his site any time soon. – Sampson Jan 28 '09 at 15:17
  • @Jonathan, I'll be trying this out in a few hours. I'm quite sure that provide a tmp dir per hosting account or something like that. I'll be proving/disproving this later today. – Dan Rosenstark Jan 28 '09 at 15:18
  • Note: edited the question with the results of my test... – Dan Rosenstark Jan 28 '09 at 16:37
  • For the record, this effects any server side language that stores its session in a shared temporary folder. In rails, at least you can make it use a database only. – Samuel Jan 28 '09 at 18:04

5 Answers5

8

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
  • 37,778
  • 11
  • 85
  • 87
  • But I can't use one of my own private directories, right, since the httpd process needs to get at it? – Dan Rosenstark Jan 28 '09 at 16:37
  • 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 Jan 28 '09 at 18:00
  • why would this not prevent access? – Dan Rosenstark May 21 '10 at 10:57
  • 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 May 21 '10 at 12:26
2

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!

genesis
  • 50,477
  • 20
  • 96
  • 125
Paul Dixon
  • 295,876
  • 54
  • 310
  • 348
1

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
  • 3,569
  • 2
  • 22
  • 20
  • You mean handle the cookie and pickup from the DB using code I've written? – Dan Rosenstark May 21 '10 at 10:56
  • 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 May 21 '10 at 14:40
1

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
  • 31,886
  • 13
  • 87
  • 111
  • What's the point? Regenerate on every web hit? – Dan Rosenstark Jan 28 '09 at 16:51
  • 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 Jan 29 '09 at 10:19
  • youre mixing up clientside session hijacking and server side session hijacking- two completely different hings – Shawn Feb 06 '09 at 19:52
0

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);

?>
Dónal
  • 185,044
  • 174
  • 569
  • 824