AppSec Blog

Session Attacks and PHP - Part 2

Yes, I will talk in this article about why it is not good to leave your session files in /tmp. But first, allow me to follow Jason's lead and talk about the session attacks he discussed in Part 2 of his ASP.NET article. I will keep it short :)

Session fixation isn't really that much of a problem as long as you stick with a few simple principles. Remember we called this blog "App Sec Streetfighter"? It's about simple and reproducible techniques that work while under attack. So lets keep it simple:

  1. Use only cookies to transport the session token. This considerably raises the bar on session fixation. The attacker now has to set a cookie which isn't easy at all.
  2. Change the session ID whenever the users state changes (logged in vs. logged out).
  3. Change the session ID every so often. (every X pageviews, every X minutes).

In order to change the session id, PHP offers a simple comand, session_regenerate_id, just add it to your header and you will get a new session ID on every page. If that works for you: great!. If it causes performance issues, then add some logic to limit the life time of sessions or add the session_regenerate_id whenever the user logs in and out.

One important caveat for session_regenerate_id: It uses one parameter. Set it to "true." The default is "false," which will leave the old session intact.

Now to the part everybody appears to be waiting for: Why not /tmp ?

/tmp is a convenient location for session data. Every Unix system I have seen has a /tmp directory that is globally readable and writable. But this is just the problem for session data. The file name itself gives away the session ID. A listing of all session files will give an attacker a list of all valid sessions. In most dedicated web server scenarios, the risk of leaking /tmp file names is low. But the defense is simple enough to "just do it" ™:

  • Create a directory which will only hold session data (let's call it /tmp/phpsessions).
  • This directory should NOT be owned by the apache user, but by root and the apache user's group.
  • Set permissions to 770. Sadly, 760 is not possible. Theoretically, it should work. PHP (the web server) doesn't really need to be able to get a list of valid sessions. But sessions will fail if you set the permissions to 760.

I typically prefer to keep my sessions in a database, less for security reasons but more for scalability. Memcached sessions is an other great way to get sessions to scale.

Related Articles:

Session Attacks and PHP - Part 1

Session Attacks and ASP.NET - Part 1

Session Attacks and ASP.NET ? Part 2

1 Comments

Posted July 1, 2009 at 12:14 PM | Permalink | Reply

Wireghoul

The directory needs to have the execute bit set so the apache user can change into the directory and then open the files. It also needs the write bit set so it can create new files and delete old files. It does however not need the read bit to list the files.
As long as the individual files themselves have group read permissions the web server can access them. I would therefore change the chmod to 730 for the phpsessions directory and 600 on the files. The files will be owned by the apache process unless you set the sticky bit so 600 on the files will work.

Post a Comment






Captcha


* Indicates a required field.