8

I was trying to understand how sessions work in PHP and found that session data is by default stored in the file system. In a shared hosting environment, session data can be read by PHP scripts written by any user. How can this be prevented ?

RobertPitt
  • 56,863
  • 21
  • 114
  • 161
Zacky112
  • 8,679
  • 9
  • 34
  • 36
  • 1
    It is possible to specify different save paths per virtual host. So it is not necessarily true that every user has access to that directory. – Gumbo Jul 14 '10 at 12:15
  • 2
    @Gumbo True, with one caveat -- if PHP is running with the uid of the webserver, there's nothing you can do to prevent virtual host a from accessing virtual host b session data. – Artefacto Jul 14 '10 at 12:19
  • @Artefacto, I agree. I believe that under shared hosting, PHP still runs as the same user for each hosting account. This is the built in security flaw that only overriding the file based handler can cure. Right? – Mike Sherov Jul 14 '10 at 12:47
  • @Mike It depends, but many do run under the web server uid. Overriding the file based handler won't help you much there, you can still read the other user script and fetch the data the way he does. – Artefacto Jul 14 '10 at 12:52
  • @Artefacto, but he can only read the other user script in the way the other user script is intended to work. – Mike Sherov Jul 14 '10 at 13:09
  • @Mike "Intended to work"? What do you mean? He can read the source and he can do exactly the same thing in his scripts, since he has filesystem level permission to read the files (if the session's stored in a database it's even simpler; he only has to fetch the password). The only thing that could possibly get in the way would be open_basedir, but that can be bypassed. – Artefacto Jul 14 '10 at 13:17
  • @Artefacto, I see. He can use PHP to read the contents of the other PHP file without it being in the context of a browser. So then no matter what he does, if an attacker was able to guess the location of certain files, there is no protection, because there is no distinction between him running PHP, and the attacker running PHP. I guess then that the only way to secure this is to make sure that your hosting company has PHP run as a different user for each hosting account? – Mike Sherov Jul 14 '10 at 14:36
  • @Mike That's correct. Better yet, each customer on its own VM. Some hosting companies provide this for 5$/month. – Artefacto Jul 14 '10 at 14:38

5 Answers5

6

You can override the session save handler for your script to use something other than the filesystem, such as a database or memcache. Here is a detailed implementation: http://phpsec.org/projects/guide/5.html

Mike Sherov
  • 13,277
  • 8
  • 41
  • 62
1

Depends on the level of access you have to the php.ini file - if you're on a Shared Hosting environment which runs suPHP and allows you to have your own php.ini file (for instance) then you can simply set the session.save_path to a path like ~/tmp instead of /tmp which is usually shared.

To begin with though, I don't think that you actually CAN read php session data from other applications. I believe it's something rather unique to the person viewing it.

Finally php Session data is not solely file system saved only. It can also be setup to save in a cookie on the user's machine or you can setup php session data to be stored in a database.

Marco Ceppi
  • 7,163
  • 5
  • 31
  • 43
  • 1
    Unfortunately, session data for other sessions is easy to read from the filesystem: $sessionFileDirectory = ini_get('session.save_path'); echo '

    '.$sessionFileDirectory.'

    '; foreach (glob('/xampp/tmp/sess_*') as $sessionFileName) { echo '

    '.$sessionFileName.'

    '; $serializedSessionData = file_get_contents($sessionFileName); var_dump($serializedSessionData); echo '
    '; } and a custom session handler is the best solution to this problem     – Mark Baker Jul 14 '10 at 12:28
  • I suppose I set up my default systems more securely because I can't emulate that on my setup. files in tmp/ are owned by the account which php is running under and are saved with 0640 so sess_xxx is owned by "marco" "marco" while others are owned by "user" "user" for instance. suPHP really helps resolve all those pesky nobody issues. – Marco Ceppi Jul 14 '10 at 14:11
1

Write your own SESSION wrapper.

For example CodeIgniter's session library doe's not depend on PHP's native one and it's more secure:

Note: The Session class does not utilize native PHP sessions. It generates its own session data, offering more flexibility for developers.

Otar
  • 2,561
  • 1
  • 20
  • 24
1

You can use session_save_path() to change the session data directory to one that isn't shared.

Hammerite
  • 21,755
  • 6
  • 70
  • 91
  • correct me if I'm wrong, but doesn't whatever you change the directory to still need to be read and writeable by the user PHP runs as and therefore still technically readable by other users of the shared hosting? – Mike Sherov Jul 14 '10 at 12:43
  • 1
    Shared hosting usually locks you into being able to read only directories and files located within your account. – John Conde Jul 14 '10 at 13:11
  • This is true. But if it's true then it's also true that any other directory (your webroot, directories with scripts in, and so on) will also be read- and writable by other users. Unless the other users are all able to exercise control over your site (and each others'), we must conclude that any sensible hosting provider has implemented a way of limiting the control a user has over directories owned by another user. – Hammerite Jul 14 '10 at 13:13
  • And that's why they invented [open_basedir](http://php.net/manual/en/ini.core.php#ini.open-basedir) – Denys Vitali Feb 11 '17 at 10:53
1

Use session_save_path() and change your session folder like "/htdocs/storage/sessions". Now sessions only saved to your given path.

osm
  • 4,186
  • 3
  • 23
  • 24