Handling sessions

sneakyimp

I have some experience with sessions, but I'm hoping someone can give me an experienced perspective because i'm about to create a catalog management application and i want to handle sessions smartly.

I know the basic idea is that the server gives each client a unique session id and that session id is used to identify that client across subsequent page accesses to the server. I understand that PHP4 has some features which supposedly can take care of this automatically...as described here:

http://www.zend.com/zend/tut/session.php?article=session&kind=at&id=2217

and here:

http://us2.php.net/manual/en/ref.session.php

QUESTION 1: What exactly does it mean that PHP 4 offers 'Automatic URL rewriting?' I would like to understand this more specifically to evaluate security ramifications. The php.net link contains ALL KINDS of warnings about security risks involving session ids getting hijacked.

I've been told by a sys admin friend of mine that php suffers performance problems when sessions are stored as serialized files on disk. He said that performance is better when a database is used.
QUESTION 2: Can anyone corroborate my friend's assertion or explain why?

There are also security warnings at php.net about folks hijacking sessions from your /TMP directory.
QUESTION 3: How could any given client access files in the /tmp folder if it's not in the html/public folder?

I've seen examples of manual session handling in phpBB's source code and am wondering if I should just use that model but I don't really have the experience to know if that's better, more work, or just plain stupid.
QUESTION 4: Can anyone recommend some best practices or a module or just good advice about session handling? I'm going to need to store some arrays and such in my sessions and want to be smart about it.

execute

Sessions are pretty safe, but as always all are hijackable... But sessions are always used and are important, just dont use session IDs in URLs, im not sure how people can get into your tmp folder, i would like to know that also.

Sessions are fine, so don't be afraid to use them, unless you are using your own credit card gateway, or you're a big company with a lot to loose, i wouldn't need to be so paranoid.

As far as security refer to forums like in my sig for that.

sneakyimp

sessions don't scare me. I've coded maybe a dozen projects that use them in the past couple of years. and, had you read the links i posted, you would realize that it is sometimes necessary to put the session ID in the URL in order to propagate it because some clients can't handle cookies or choose not to.

And as for checking the links in your sig to answer my questions about security, i visited the site you're spamming for and it has literally zero answers for me. That's why i posted it here--to get some answers.

execute

ok first of all dont get so offensive.

Secondly, you do not NEED to use session IDs in links, but yes you may want to to support browsers with no cookies, or people who refuse to add them. But it is still a security risk. And it's not search engine friendly. There aren't that many people that disable them anyway, they probably don't know how.

You didn't check the links in my forum, if you had i would be aware of it. I said forums, and you clicked on the articles 🙂. (same IP).

I highly doubt you used sessions in many projects, because if you had, you wouldn't be asking these begginer questions about it. And then having the nerve to question someone elses expertise about it.

sneakyimp

I'm really psyched you're trying to help me here...

If you cannot propagate the session id in cookies, then how else do you propagate them on the client end? I checked the 'Web Development Forums Link' in your signature as instructed, and found exactly 0 posts on PHP topics. If I'm not looking in the right place, please let me know. Or perhaps I missed it in the articles section?

Lastly, before you start calling me noob, please provide at least one answer to my questions.

Thanks again for all the help!

thorpe

Q1: What this means is that php4 has the ability to automatically add a users session ID to the end of a URL. Saves you having to track it yourself.
Q2: I cant realy collaberate with your friend in saying that storing your sessions in a database is more efficient than purely on the filesystem. I assume a database may even be a little less efficient. Afterall, It needs to store the data on the filesystem somehow, so Its kinds adding an extra layer.

However, having said that. There are allot of advantages to using a database to store session data. For starters, a database can be queried quite simply, so making things like a who's online script becomes childsplay. I have used my own custom built session handler class for a long time, and have never noticed any performance hit, and the benifits gained would make up for anything anyway. Have a look at the [man]session_set_save_handler[/man] for some simple examples of creating your own session management.

Q3: If the server is setup properly, this should not be possible.

Though then again, anything and everything is possible.

Hope this helps some.

execute

sneakyimp wrote:
I'm really psyched you're trying to help me here...

If you cannot propagate the session id in cookies, then how else do you propagate them on the client end? I checked the 'Web Development Forums Link' in your signature as instructed, and found exactly 0 posts on PHP topics. If I'm not looking in the right place, please let me know. Or perhaps I missed it in the articles section?

Lastly, before you start calling me noob, please provide at least one answer to my questions.

Thanks again for all the help!

1) I apologize, you did see my forum, you're right it's a new forum, and there is no security php posts about this subject... but the reason why i directed you there is so you could start one and therefore someone would reply, i have a few good PHP experts there, and since its such a small forum, you would get more attention. I was just trying to help.
2) "If you cannot propagate the session id in cookies, then how else do you propagate them on the client end?" You use cookies, if they have it disabled you use PHPsession Ids in URLs, but that's a security risk, and since most users dont disable cookies, it won't be a problem, since they are usually not very bright and use IE, disable cookies, and expect to be safe.
3) I did try to answer your questions, Sorry I didn't number them... I don't really know how people can enter into your TEMP folder, because you would need some sort of access, port scans, and vulnerability exploits on your server, all of which would probably not interest a hacker unless you got a lot of money there.
4) Your first question, is about the ability that PHP has to add something called PHPSESSID= (the default) to the end of your URL, so that when you session_start, on the next page, you don't loose your session. But like i said it's not very safe, its not Search engine optimized, and really pointless for me.
5) Your second question, about your admin friend, says what? Performance flaws? Sure maybe a few seconds off here and there, but that's not too important, but since he probably works for a big company, maybe he knows what he's doing, but i doubt it's useful for what you're doing, the difference is probably trivial. Database is probably less secure, since they can inject it, and files they would need to be serious hackers...

sneakyimp

thanks guys...i'm starting to feel like my questions are legit...hope you can deal with all the questions here:

thorpe wrote:
Q1: What this means is that php4 has the ability to automatically add a users session ID to the end of a URL. Saves you having to track it yourself.

What, exactly, does that mean that is 'has the ability' to automatically add the sid to the url? Does that mean that the session id will ALWAYS be created and defined with php 4? What happens when cookies are turned off? does PHP automatically add a session id to each and every relative URL? Are these session IDs visible to users? The concept of 'url rewriting' is kind of puzzling to me.

phpBB's source code takes great pains to ensure that the session id gets propagated thru URLs if necessary. They demand that ALL urls have to be wrapped in a function call append_sid(). the source:

//
// Append $SID to a url. Borrowed from phplib and modified. This is an
// extra routine utilised by the session code above and acts as a wrapper
// around every single URL and form action. If you replace the session
// code you must include this routine, even if it's empty.
//
function append_sid($url, $non_html_amp = false)
{
        global $SID;

    if ( !empty($SID) && !preg_match('#sid=#', $url) )
    {
            $url .= ( ( strpos($url, '?') != false ) ?  ( ( $non_html_amp ) ? '&' : '&amp;' ) : '?' ) . $SID;
    }

    return $url;
}

Is that function in phpBB's source code overkill, unnecessary, or best practice? It seems like a total pain in the ass to me.

Execute had a really good point about search engine issues. I think the googlebot is smart enough to deal with the session ids--i haven't had any problems with my other sites. My concern is mostly about PHP4's 'ability to add a session id to the URL'. Does the PHP url rewriting functionality sniff out the browser agent and skip adding the URL for bots? Surely bots aren't smart enough to drop session IDs? At any rate, if I use the phpBB approach I could put in my own user agent sniffer to drop session IDs for web crawlers.

I had already read the man pages on session_set_save_handler() and it seems to make sense, but i was wondering why the function for session_open requires a file path?? If my plan is create custom session handling functions that use mySQL, what is the significance of the save path? The php man pages don't offer much help in understanding what goes on with the save path (nor do the zend pages).

As for performance of a database vs. file-based session storage, I'm not sure where the performance issue might lie, but I seem to recall it had something to do with disk fragmentation and garbage collection on busy web servers. Many sessions would mean countless little files on the hard drive. The PHP man pages warn "Note: On some operating systems, you may want to specify a path on a filesystem that handles lots of small files efficiently. For example, on Linux, reiserfs may provide better performance than ext2fs. "

execute: thanks for the info.

sneakyimp

so i've been looking into the automatical url rewriting thing and it sounds to me that PHP4's built-in url rewriting is very simliar to phpBB's append_sid() function. After some googling, it appears that many folks are having issues with search engines either neglecting their site or bots crawling an infinite number of files because the session id is always different. Here's an example about osCommerce:

Session ID's in osCommerce
One of the first issues surrounding osCommerce and spider friendly URL's is the Session ID. Many default versions of osCommerce pass the Session ID value through the URL. You can usually see the 'SID' or 'osCsid' Session Name/Value pair passed thru the URL. While this makes the script usable for those without browser cookies, search engines will avoid any URL's which appear to contain a long session string. Instead, using a cookie to store the Session ID (Value) is the preferred method. Simply put, passing the Session ID through the URL's in osCommerce will make your URL's unfriendly to many search engines, as the URL's will continually change on each visit. This will create a new set of page URL's for the search engine spider/bot to crawl on each visit, which is very unfriendly. Search engines will typically avoid URL's which contain any Session ID's, or anything that looks like a Session ID. Luckily, this issue can be corrected without too much effort.

Unfriendly URL Example
http://www.jjwdesign.com/catalog/index.php?cPath=30 &osCsid=5156e8975ce0d4cdbb13a70f48ea797d
This can be easily corrected thru the osCommerce Admin tools; Configuration section. Just set the values below and you should no longer see the osCsid Session Name/ID in your URL's.

Admin -> Configuration
My Store
- Use Search Engine Safe URL's = True
Sessions
- Force Cookie Use = True
- Prevent Spider Sessions = True

If you are still seeing Session ID's/Values being added to your URL's, such as SID, then PHP might be adding the Session ID automatically. This was sometimes the case with PHP3. Just add the following lines of code to catalog/includes/application_top.php.

// Do not pass the Session ID thru the URL, use cookies only.
ini_set("session.use_trans_sid", 0);
// Use only cookies for session management.
ini_set("session.use_only_cookies", 1);

I've also heard that mod-rewrite for apache can be helpful but all of this sounds like overkill to me. i suppose i'll go read that osCommerce code.

sneakyimp

Also, I spoke to my sysAdmin friend about using file-based session storage. He said that these files can become a bottleneck on a very busy site because of the fact that it requires the file system to handle tons of teeny weeny files. Each session requires a different file to be located on the hard drive, and performance issues arise when a large number of sessions result in files scattered all over your drive. The 'seek time' of a hard drive--one of the slowest parts of disk info retrieval--really comes into play.

in contrast, a database session storage scheme will result in a single large db table file for your session info which will likely be cached by the db system. Also, if in a DB, you might also be able to query the session data from multiple servers if you need to. Ultimately, it gives you more control as thorpe pointed out.

execute

What happens is, there is a PHP trans ID thing in your php.ini and when you activate it it adds PHPSESSID to the end of each link in your website.

And bots are dumb, don't expect anything from them except pain.

sneakyimp

yep, dealing with search engine rankings is a hassle, but necessary. it's sounding to me like i should disable trans-sid in PHP and deal with non-cookie propagation of a session ID with my own function which is smart enough to drop it for bots.