Yes, exactly what
m3rajk said.
Sessions are wonderful, wonderful things, because they make things very easy for us developers. However, at some point in your programming life its critical to understand exactly how any given peice of code works.
The quick and dirty view of sessions is that they stored all the session variables for a given person in a file indexed by the PHP generated session id. The user's browser is responsible for somehow providing your server with this id on every page view. (HTTP is a "stateless" protocol, this means that there is no way for the server to know that two requests are coming from the same person, we have to somehow "trick it" into carrying state around.)
The simpliest way is to stick variables in the URL aka GET (?phpsessid=asdfksadf). However, many people feel this makes ugly URLs. It also make it easier for the user to "mess with" the session id. You can also stick the session id in a hidden form element, but that will then require all your pages to use form-buttons to navigate. Cookies are the next option. A cookie is a little file sent to the browser by the server. Browsers "know" to send the cookie back on every page view to the server that issued it. Users can still "snoop" around in their browsers "cookie jar" to find and edit cookies. All PHP does is automate the use of one of these methods for sessions. Typically it tries to use cookies first, and then fallback to GET.
I think PHP has made it a little too hard to truly "secure" a session and while I still use them I plan to write my own session library "soon". You can see some of my "testing" work in a thread
here.
The security tools I talked about mcrypt and MAC'ing:
mcrypt is an encryption library (check out
http://php.net/mcrypt for more information on it). It is a collection of two-way, secret key algorithms. This means that you can encrypt and decrypt something. This is useful for "hiding" sensative information. For instance you might want to encrypt the session cookie before sending it, even if using SSL, to hide the cookie's data from the user. Also you might want to encrypt sensative information in your database, such as cc#'s, or phone-numbers, if you don't need to search on them to often and want to protect your user's privacy.
MAC'ing (Message Authentication Code): are used to check if something has been tampered with. Typically speaking MAC'ing uses a one-way hash, such as MD5 (use php's MD5() function). What you do it you MAC the value with a secret and then append the MAC to the value. You then send the whole composite as the message. If anyone tampers with the value, when you get it back and re-MAC it the values won't match and you know to reject the data.
E.g.
Code: Select all
$data="Foo";
$mac = MD5($data."SECRET STRING");
$data = $data . "+" . $mac;
// send cookie with data payload
...
// get cookie back on later page
$data = $_COOKIE["data"];
$crumbs = explode("+",$data);
if ($crumbs[1]!=MD5($crumbs[0]."SECRET STRING"))
{
// reject data, attack in progress
}
else
{
//safe
}
Does this answer your question? (And probably raises many more

) For more about encyption and its uses check out
http://rsasecurity/rsalabs/faq/