Cookie和存储中的PHP会话ID

Question

I've read multiple comments about encrypting PHP session data, in case it is stored in a temp directory that is available on multiple accounts on a shared server. However, even if the data is encrypted, session_start() still generates filenames containing the session_id. For example,

sess_uivrkk2c5ksnv2hnt5rc8tvgi5

, where uivrkk2c5ksnv2hnt5rc8tvgi5 is the same session id I found in the cookie my browser received.

How is this problem typically addressed / could someone point me to an example? All of the simple examples I've found only address encrypting the data, not changing the filename.

Just to see what would happen, I made a SessionHandler wrapper that would do an MD5 hash on the $session_id variable before passing it on to its parent function, but that did not work. Instead, I ended up with two files: a blank one (with session_id as a part of its name) and a full one (with an MD5'ed session_id). Also, there was the problem of close() not accepting session_id as a parameter, so I couldn't pass it on to its parent.

EDIT: I 'm learning about php sessions, this isn't for a live commercial site, etc.

Answer 1

Yes, in some scenarios (ie a very incompetently configured server - although these do unfortunately exist) on a shared server your session data may be readable by other people. Trying to hide the session files by changing their names serves no useful purpose - this is described as "Security through Obscurity". Go and Google the phrase - it is usually described as an oxymoron.

If your question is how do you prevent other customers accessing your session data on a badly configured server then the sensible choices (in order of priority) are:

• switch service provider
• use a custom session handler to store the data somewhere secure (eg database) There are lots of examples on the web - quality varies
• use a custom session handler to encrypt the data and use file storage. Again you don't need to write the code yourself - just scrutinize any candidates

If you want to find out if your provider might be a culprit - just have a look at the value of FILE . Does it look as if you have access to the root filesystem? Write a script which tries to read from outside your home directory. If you can't then the provider may have set an open_basedir restriction (it is possible to get around this - again Google will tell you how).