funcptr - php

User sessions, what data should be stored where?

2013-08-25T13:05:00+00:00

This article has been updated. For the old version please check Archive.org</a>

A couple of days ago on reddit.com</a>'s /r/netsec</a> a poster by the name of Dan Weber</a> posted what he believed to be an attack on PHP sessions: Hacking PHP sessions by running out of memory</a> (reddit link)</a>. The way the "attack" works is as follows:

Create a new session</li>
Assign some new data to the session, in this case a username which is used to signify that the user is logged in.</li>
Check to verify that the user should be logged in</li>
If the user should not be logged in, destroy the session.</li> </ol>
The "attack" would be to run the PHP</a> script out of memory on number 3, since once something is set on the session it is immediately stored, so even if the user is not supposed to be logged in, they are now logged in since their session says they are.
I wouldn't necessarily call this a PHP hack, this is really just bad practice in terms of programming, the logic should be reversed.

Create a new session</li>
Verify the user should be logged in</li>
If so, set the session data</li>
If the user should not be logged in, don't set the session data</li> </ol>
That would solve the problem at hand, and now there is no way for the user to trick the PHP script into believing she is logged in when that is not the case.
However as the discussion went on on Reddit, it became even more clear that there are no good resources on what you should store in the user session, and what you shouldn't store in the user session. Some of these things may seem like common knowledge, but sadly this is something every single new person to programming has to learn on their own.
Some assumptions</h2>
Let's get this out of the way, this is in no way limited to PHP, but it is the one I will be using as an example. This can all apply to Ruby (Ruby on Rails</a>), Python (Pyramid</a>) or many other frameworks.
The basic problem is that generally writing to the session is not an atomic transaction based on the page accessed, so the assumption made in this article is that when you write to the session it is instantly committed, and there is no way to roll it back upon failure. If there was, our first example listed wouldn't be able to occur since upon running out of memory at step 3, the session would have been rolled back and cleaned up.
What should you store in the users session?</h2>
You should only really store anything in the session that if it were made public it would do very little harm.
Really the list of items to be stored in a session are as follows:

The users unique id (The ID that allows you to retrieve the users information from storage)</li>
Temporary state (i.e. Flash messages)</li>
CSRF token</li> </ol>
More importantly, don't store permission bits, or group memberships, or anything that is used to allow/deny access to particular resources. You want to store just enough information that upon a user accessing your site you are able to retrieve the users information from storage, and based upon that information from storage you then make decisions such as permissions/group memberships.
Why is this important?</h3>
One of the things that Dan Weber brought up in the Reddit post was storing the users permission level and group membership in the session. If your code is then relying on the session to always contain the right permission level, then there is no way to expire someones access to the data.

A user logs in</li>
A user gets various permissions, and they are set in the session</li>
The user has been fired from his job, and an administrator removes the users permissions</li>
Since the user is still logged in, the users permission bits are still set, and he continues to have access to parts of the site/information he shouldn't have access to.</li> </ol>
If instead on every page visit we simply pull out the users unique id and verify the permissions upon access, as soon as the permissions are revoked by the administrator the user no longer has access to the various resources.
Temporary state</h3>
There has to be an easy way to remember something from page visit to page visit that isn't considered detrimental if the information gets lost. One of those things is flash messages. Flash messages are generally used to provide the user indication that something has changed, they are shown once and then never again.
Storing these as session data makes sense. If the flash message gets set, great, if it doesn't get set, it doesn't matter. Flash messages are simply a notification tool, if the user misses them it isn't important.
What you shouldn't store in the session</h2>
Definitely don't store any kind of permission bits, groups a user is a part of or anything that would allow the user access that they normally would not be able to access.
On each page access check what permissions the user has. While it may mean a little more heavy lifting server side it provides extra security, and the means to enforce changes in permissions instantly.
Good secure programming practices</h2>
Keep secure programming practices in mind at all times, always consider how the information you are storing/processing is accessed/viewed/administered. More importantly think about the access controls that are in place, and how one could expire access to a particular resource without requiring a co-operative client.
The ordering of how variables are set, and when they are set are very important. $_SESSION['isadmin'] = True</code> at the top of a PHP script, and then removing it by checking to see if the user is actually an administrator later on in the script is a bad idea.
Always order your code so that if a failure does occur there is no chance that a critical section of your code is executed by accident, or that information is stored in a half-verified state. This is especially important for access control.

Apache mod_fastcgi and PHP with PHP-FPM 2010-11-14T23:37:27+00:00 Recently I did a server migration from an older server to a newer server and in an attempt to help stability I wanted to see if there was a better way to do PHP FastCGI. In my research I came across running PHP using the FastCGI server that spins up a PHP on a TCP/IP port and allows the web server to connect to it. However this doesn't help with spawning or keeping track of instances or error recovery. This is where PHP-FPM</a> comes in handy. It does all of the hard work for us, it spawns the processes and has a bunch of really awesome features that help run PHP as various different users as required with different PHP ini files and memory limits. PHP-FPM's defaults, at least from a ports install, are extremely sane and I don't really suggest changing them. After setting up PHP FPM I had to set up Apache. mod_fcgid</code> doesn't allow for remote connections, and as such I was unable to use it for what I needed it for. mod_fastcgi</code> provides the FastCGIExternalServer</a> configuration key, which is exactly what I needed. "The FastCgiExternalServer directive defines filename as an external FastCGI application. If filename does not begin with a slash (/</code>) then it is assumed to be relative to the ServerRoot</code>. The filename does not have to exist in the local filesystem. URIs that Apache resolves to this filename will be handled by this external FastCGI application." </blockquote> What this documentation does not state is that the path up to the last part of it has to exist in the local file system. So in my first couple of attempts I pointed it at /usr/local/www/fastcgi/php5.fcgi</code> without having an actual fastcgi directory located in /usr/local/www/</code>. There are a lot of examples that require creating a new FastCGIExternalServer</code> for each and every VirtualHost</code> this is unacceptable to me, the reason they require it is because they set the FastCGIExternalServer</code> path to the folder where they are going to be serving files from. In the end I found that after creating the /usr/local/www/fastcgi</code> directory (and reading the mod_fastcgi</code> source code) that all it does is make Apache believe a file exists in a certain directory, much like Alias</code>, except Alias</code> allows full paths to be aliased, not so here. The AddType</code> and Action</code> add custom types and what the action should be when such a type is encountered. In this case the action is to redirect the request to /php5.fcgi</code> which will handle the rest of the request. This does not require another FastCGI section per VirtualHost</code> as each PHP request will just get shuttled to the php handler. Do take note that I have specifically disallowed Apache to serve anything from the /usr/local/www/fastcgi/</code> folder, except for a single file php5.fcgi</code> which is our FastCGIExternalServer</code> file. <IfModule mod_fastcgi.c> Alias /php5.fcgi /usr/local/www/fastcgi/php5.fcgi FastCGIExternalServer /usr/local/www/fastcgi/php5.fcgi -flush -host 127.0.0.1:9000 AddType application/x-httpd-fastphp5 .php Action application/x-httpd-fastphp5 /php5.fcgi <Directory "/usr/local/www/fastcgi/"> Order deny,allow Deny from all <Files "php5.fcgi"> Order allow,deny Allow from all </Files> </Directory> </IfModule></code></pre> Note that even-though in my last post</a> concerning mod_fastcgi</code> I as moving away from it, I am now doing the opposite, instead of moving from mod_fastcgi</code> to mod_fcgid</code></a> I'm back to mod_fastcgi</code>, only because mod_fcgid</code> doesn't offer the same functionality. So far this has provided far more stability, along with PHP-FPM doing all of the process management I can now use a single PHP instance that is running on a single port for the various web servers I am testing. At the moment I have both Lighttpd and Apache using the same PHP-FPM instance. It is faster, less memory is wasted and PHP-FPM is much better at process management than mod_fastcgi</code> or mod_fcgid</code>. FastCGI quick and dirty 2006-09-13T00:19:31+00:00 In this quick and dirty guide for FreeBSD I will assume you have already compiled and installed PHP5 with fcgi mode enabled, which can be checked by running: /usr/local/bin/php-cgi --version</code></pre> I will also assume you have installed mod_fastcgi</code> from www/mod_fastcgi</code> in the ports. Create the fast cgi ipc temp dir, make sure you place this somewhere it will keep existing: cd /var/tmp mkdir -p /var/tmp/fcgi-ipc/dynamic chmod -R 0777 /var/tmp/fcgi-ipc</code></pre> Let's create the directory where we are going to place our PHP wrapper, this config is for server wide using the same FastCGI PHP config. This is on purpose, since it will allow server wide PHP usage. If you want you could then split it up into virtualhosts if one required a standalone php running for that. mkdir /usr/local/www/fastcgi-bin/ chmod 755 /usr/local/www/fastcgi-bin/</code></pre> Next up we create the very simple wrapper: cat << EOF > /usr/local/www/fastcgi-bin/php5.fcgi #!/bin/sh # To use your own php.ini, comment the next line and uncomment the following one #PHPRC="/usr/local/etc" export PHPRC PHP_FCGI_CHILDREN=8 export PHP_FCGI_CHILDREN exec /usr/local/bin/php-cgi EOF</code></pre> Set PHP_FCGI_CHILDREN</code> to whatever value you want, that is how many processes it will use. I suggest the standard which is 8, if you make it more, you use more ram, you make it less Apache will have to wait if all of the PHP processes are in use. Next up, make it executable: chmod +x /usr/local/www/fastcgi-bin/php5.fcgi</code></pre> Last but not least, edit httpd.conf</code> and make sure to add a comment in front of the mod_php5</code> line, and uncomment the mod_fastcgi</code> line. Then add this to the end of your Apache config: <IfModule mod_fastcgi.c> FastCgiIpcDir /var/tmp/fcgi-ipc/ FastCgiConfig -pass-header HTTP_AUTHORIZATION AddHandler fastcgi-script .fcgi .fcg .fpl Action application/x-httpd-php5 /fastcgi-bin/php5.fcgi AddType application/x-httpd-php5 .php .php5 </IfModule> ScriptAlias /fastcgi-bin/ "/usr/local/www/fastcgi-bin/" <Location /fastcgi-bin/> Options ExecCGI SetHandler fastcgi-script Order allow,deny Allow from all </Location></code></pre> That's it. Restart apache and watch as the first time you access a PHP script FastCGI will spawn several of them, and they start serving requests. Load usage may seem higher, that is because unlike Apache the standalone running PHP's handle the jobs as they come in with whatever one is first, Apache will try to put as much work in one of its preforked modules. As the PHP processes come and go through FastCGI the memory usage will go up and down. Mine has an average of about 300 MB, which is very good compared to the 800 MB Apache with mod_php</code> would rack up.