0

Im running webserver Apache/2.2.17 with PHP 5.3.5-1ubuntu7.2 and noticed that PHP is creating sess_null files within /tmp directory. That leads right to session hijacking.

Here;s session section from php.ini:

session.auto_start  Off Off
session.bug_compat_42   Off Off
session.bug_compat_warn Off Off
session.cache_expire    180 180
session.cache_limiter   nocache nocache
session.cookie_domain   no value    no value
session.cookie_httponly Off Off
session.cookie_lifetime 0   0
session.cookie_path /   /
session.cookie_secure   Off Off
session.entropy_file    no value    no value
session.entropy_length  0   0
session.gc_divisor  1000    1000
session.gc_maxlifetime  1860    1860
session.gc_probability  1   1
session.hash_bits_per_character 5   5
session.hash_function   0   0
session.name    PHPSESSID   PHPSESSID
session.referer_check   no value    no value
session.save_handler    files   files
session.save_path   /tmp    /tmp
session.serialize_handler   php php
session.use_cookies On  On
session.use_only_cookies    Off Off
session.use_trans_sid   0   0

That's mostly the default values.

Have somebody had problems like this and can help me?

Thanks

CountZero
  • 2,844
  • 4
  • 22
  • 20

2 Answers2

1

If the filename is sess_null, this looks like the the session_id has been set to null. By default PHP creates the filename prefixing the id with sess_.

I would assume (I can only assume because you don't have posted your code), that you set the session id to "null" somewhere in your code. A function to set the session id is session_idDocs.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • Unfortunately that's not the case. I found one call to session_id() that could have been called with possibly empty/null param, but adding checks around it did not solve it for me. And it seems to be the only call out there. Thing is im working with legacy code that have just been moved to fresh virtual machine and i don't have access to old server configuration, debugging this issue is rather difficult. And tips and suggestions appreciated – CountZero Oct 05 '11 at 09:26
  • If you know where sessions are stored, you could dump the `session_id()`; before storing/closing (`session_write_close()`) or destroying (`session_destroy()`). See as well: [How to tell if a session is active](http://stackoverflow.com/questions/3788369/how-to-tell-if-a-session-is-active/7656468#7656468) - I created a function that works with PHP 5.2 or PHP 5.3, maybe even an earlier PHP version and PHP 5.4 has a build in solution. – hakre Oct 05 '11 at 11:02
0

How I handle this on a server handling multiple sites.

Keep sessions from /tmp by setting a new path one dir BACK from web root. Keeps it out of /tmp. So if your web root is /home/username/web_root, your sessions end up in /home/username/sessions, out of the web accessible path, and not in /tmp. The following ssumes all your user executable are at the same level! As I call a single script with mod_rewrite every time, this works for me.

ini_set('session.save_path', realpath(dirname($_SERVER['SCRIPT_FILENAME']) . '/../sessions') );

Other simple stuff I do: Start session and give me a nicer handle.

session_start();
$s =  &$_SESSION;

Authenticate code simply sets a flag which I check before each operation requiring auth.

$s['user']['authenticated'] = true;

Logout code destroys the session:

session_destroy();

Logout ALL users of that one site:

rm -f /home/username/sessions/*
Daren Schwenke
  • 5,428
  • 3
  • 29
  • 34