By default PHP's session system is very insecure.
First of all, the session identifier PHP generates is not very secure, but should serve its purpose in basic websites. For more paranoid and security important applications, it is a must to have stronger SESSID's. You can customize the behavior of this like already stated in the previous post.
By default, the session identifier is something like this:
Code: Select all
$_SERVER['REMOTE_ADDR'].time().microtime().((float) mt_rand()/(float) mt_getrandmax())*10
The IP address is very potentially known by the attacker and so is the time (e.g. leaked in HTTP) and the microtime is a small factor. The only piece of information that makes it usable is the use of linear congruential generator.
Often when people create own session identifiers in own session systems, they might use something like uniqid() for that. That is not very secure. It's almost the same as the built-in session identifier. uniqid() is similar to this:
Code: Select all
sprintf("%s%08x%05x%.8F",'',$sec,(($usec * 1000000) % 0x100000),((float) mt_rand()/(float) mt_getrandmax())*10)
At this point you might think that I'm harsh and just throwing thoughts from my head, but believe in me. I know this stuff, I've coded several C++ and Assembly random generators and analyzed how this kind of stuff works. And if you do not believe in my sayings, test yourself by running this code:
Code: Select all
list($usec, $sec) = explode(' ',microtime());
echo sprintf("%s%08x%05x",'prefix',$sec,(($usec * 1000000) % 0x100000)),'<br>',uniqid('prefix',false);
You will see something similar to this:
prefix499ca49c6a924
prefix499ca49c6a948
First it ouputs "my own PHP uniqid()", then the PHP's internal uniqid(). The last 2 characters are different, because the microsecond has moved forward because the execution of those functions does not happen so fast.
The fact is, whether you use PHP's session system or not, you are often vulnerable to many attacks. For instance, the session storage attacks are very possible in most implementations. There are several things to remember and implementing your own session system is harder than you might think at first; you have to create strong session identifiers, prevent fixations, many kind of hijacking attempts, poisoning attacks, storage attacks, transactional processing must be taken care of, and last, but not least, you have to prevent race conditions and any other potential issues that raised, because of lots of new code you just created.
Even if you use stronger session identifiers and protect from hijacking and fixation, you are still in risk. Also, many applications tend to move their session system into the database. Is that a good approach? That depends entirely how educated the coder was/is.