Sessions and Cookies

Working with Sessions and Cookies in PHP and MYSQL

Security is an essential component for any site to be successful. However, adding security can increase overhead and annoy your users if not done properly. In this tutorial, I will discuss common problems that are encountered when using sessions and cookies.

Cookies

Cookies are ways for the user to be identified by a website. For instance, a site will create a cookie with the name: “favorite_color” and the value: “red”. Now, each time that you visit the site, it will load the cookie and establish that your “favorite_color” is “red”. This can be quite effective in remembering users, so a user does not have to log in each time they visit your site. The “Remember Me”, seen in many sites, uses this method. However, this can also create some serious security holes. One example is not verifying what the cookie returns to your site. After some simple searching, I found a website with a user panel script. It output all my login information in cookies and loaded the values each time I preformed an operation. For instance, if I left a comment, it would output whatever my name was from the cookie name variable. Now using firebug and some add-ons, I could not only view these cookies but also edit them. So every time I edited the cookie containing my name, the site would not validate my name but just output it instead. Also I could change my user ID, and eventually was able to find the user ID of the admin (001) and gain full admin privileges.

Example

// Setting a cookie in PHP is easy
set_cookie(name, value, expiration, path, domain, secure, http_only);
 
// Name is what your cookie will be stored as.
// Value is the value that will be stored in your cookie.
// Expiration is when your cookie will expire (delete).
// Path is the path on the server the cookie will be available to.
// Domain is the domain that the cookie is available to. (Note: www.example.com counts www as a subdomain of example.com)
// Secure is if the cookie will be only transferred over a secure connection SSL.
// HTTP_only will send the cookie only through HTTP protocol. (Note: only available for PHP 5.2 +, and on certain browsers)
 


 

Sessions

Sessions are variables that are stored on your server to identify a user. As opposed to cookies, users cannot directly modify them – but there are still security risks involved. There are two main threats for sessions: Session Fixation and Session Hijacking.

Session Fixation

Session Fixation is when a user goes to an already established session and loads their information into that session. By going into an already established session, the attacker can visit that session and gain the information that the user has inputted. A simple example of this is if you click on a link of a website where the session id has already been established. Such as, http://www.example.com/?PHPSESSID=1234. Now the attacker knows to go to the same PHPSESSID to view your information.

Session Hijacking

Session Hijacking is the second type of risk, and is much harder to defend against. This is where the attacker can obtain your session id by packet sniffing or various other methods. For example, the attacker can be connected into your network and filter all of your data that is being sent to your router. Once your session ID has been obtained, he can visit that ID to gain access to all of your information.

Example

// Working with sessions is quite easy, first thing you have to do on everypage is begin the session.
session_start();
// Then you can set the variables for the user
$_SESSION['username'] = "nettuts";
$_SESSION['website_url'] = "www.net.tutsplus.com";
 
echo $_SESSION['username']http://www.blogger.com/blogger.g?blogID=7039785605723778971#editor/target=post;postID=6883759240158640360; // Will echo "nettuts".
 

 

Using Sessions Effectively

Coding a login script is outside the parameters of this tutorial. But I will show you how to make your current login script more secure. Using sessions is generally more secure than using cookies. This is because users cannot change session values as easily as they can change cookie values. This is why I like to store all my user variables in session variables. Another important tip is to never trust user input. You always want to verify what the user inputs with values in your MYSQL database and then output to the session accordingly. Consider changing your login function to something similar to the following function:

Example

 
function login($username, $password)
		$sql = mysql_query("SELECT id, user_level FROM users WHERE password = '" . $password . "' AND username = '" . $username . "' LIMIT 1");
		// If there are no matches then the username and password do not match
		if($sql === false) 
		{
			return false;
		}
		else
		{
			while($u = mysql_fetch_array($sql))
			{ 
                session_regenerate_id(true);
                $session_id = $u[id];
                $session_username = $username;
                $session_level = $u[user_level];
 
                $_SESSION['user_id'] = $session_id;
                $_SESSION['user_level'] = $session_level;
                $_SESSION['user_name'] = $session_username;
                $_SESSION['user_lastactive'] = time();
				return true;
			}
		}
 

 

Conclusion & Session Hijacking

Session Hijacking is extremely complicated to protect against. You might have read some suggestions to use a combination of the user’s IP address or User Agent to create a fingerprint. However, this is all ineffective to your actual users. Users IP’s change all the time; for big ISPs, such as AOL, they change every few minutes. This would create a huge problem. User Agents can also change — it has been recorded that, in IE7, the user agent can change at times. The best way to protect against hijacking is to write a token system. This is a system that will output a cookie on each page load and store that value also in your mysql table. It will then match the cookie value with the MySQL table value. If they are not equal, then the session will be invalidated These are some basic functions to teach you how to work with sessions and cookies. Of course, for more protection, you need to add more cookies to validate against. This level of protection is not enough for protecting extremely valuable information, but it should get you started! Some closing notes: Always ensure that cookie values are valid. Never output a password to a session or cookie variable. Use session_regenerate_id to prevent against session fixation. Please subscribe to the Theme Forest RSS Feed, and follow us on Twitter.