Cookie and Session Fixation
Cookies or sessions are used with all membership scripts, whereby allowing the Website user to stay logged in. It’s a personal preference whether to use cookies or sessions but sessions add extra end-user security, where the session will always expire should the browser be closed (and for those using Windows-based servers, after a specific period of time).
There are many different types of security exploitations hackers can sink their teeth into, some of the most common are SQL injections, where the hacker exploits SQL statements by adding extra code to the statement that tampers with the existing statements within. This can be easily rectified and many new programmers think this is the end of their worries with security-related issues in PHP – but unfortunately there’s more. Don’t blame PHP, these apply to every single programming language out there (especially ASP, too). In-fact, we blame it on the browser really as this is where Cookie Fixation really happens.
Cookie Fixation is where cookie values are tampered with to make it look like the hacker is logged in as a specific user of the site. So they could login as ‘hacker123′ and they see another user is logged in too, they’d use a simple software (or add-on in Firefox) to modify the cookie’s value to change it to that specific username. This is, if the cookie value is assigned to the users’ username.
Most scripts apply permissions based on whether they’re “logged in” and who they’re logged in as. So you’d add $_COOKIE['LoggedIn'], for instance to a SQL statement, and if that username in the database has a value of 2 in field ‘permissions’, then give them administrative permissions. Hence, if some kiddie-hacker changed the session or cookie value, well – its obvious!
So, this is obviously something we don’t want therefore we need to take some measures when setting cookies, etc. It’s a pretty simple task and really, no-one needs to be an expert to fixate cookies/sessions so its best to take action to prevent such thing occurring – it may have bad consequences to your database should administrative powers allow database modification via the application.
So first of all we want to add md5 a random password to a seperate cookie, as well as the users’ password (which is also md5 hashed). This may not be the most secure solution but its better than not having it at all. Research on Google is also essential. So that being said, for every page that the user can be logged in on, we include a seperate file that checks that the seperate cookie is set (active), and that the cookie equals the password or value you have made, and the password of the user (and you’d get this by SELECTing it in a query based on the users’ username in the other cookie). That other cookie will just have the username of the user that is logged in. But if you think logically, if they try to change this cookie’s value, it won’t work.
$_COOKIE['LoggedIn'] // this is the cookie with just the username
$_COOKIE['CheckValidation'] // this is for validation, the cookie with your value and the users’ password
Why won’t it work? Basically because if they try changing $_COOKIE['LoggedIn'], unless their password is the same as the previous user, they’ll be refused entry. This is because we’ll include the seperate file at the top of each page, if everything doesn’t work out and it seems the LoggedIn cookie has been tampered with, then we’ll display an error and use the exit() function below to prevent anymore code from being executed by PHP. Pretty simple stuff huh? Of course, this is not the best way of preventing Cookie Fixation but of course its a start for you which you can upgrade by with research!
So first of all when the user logs in, we’ll add the following two cookies:
setcookie("LoggedIn",$username,time()+604800);
setcookie("CheckValidation",md5("this is your md5 password, make it something random!").$query_username_ob->password,time()+604800);
Note: as you can see ($query_username_ob->password) I have queried for the password from the new account in the database, then fetch_objected it, to return values of the specific fields. This is just an extra security measure just in-case you’re trying to figure out what it is for.
Obviously we’d do this once we validate the user and password matches in the database. After, create a seperate file that is included in each page, with the following code:
$session=$_COOKIE['LoggedIn'];
include(“config.php”);
if($session) { // is user is logged in
$password_check=mysql_query(“SELECT `password` FROM `users` WHERE `username` = ‘”.mysql_real_escape_string($session).”‘”) or exit(include(“error.php”)); // SELECT the password followed by a fetch_object to get it from the database
$pw=mysql_fetch_object($password_check);
if(!$_COOKIE['CheckValidation']) { // so if they tried deleting the cookie, don’t let them in
echo “< p style='font-size:20pt;font-weight:bold;color:red;'>UNAUTHORISED ACCESS: You need both cookies active to use this site! If you received this message in error, < a href = 'logout.php'>Logout and log back in.“;
exit();
}
elseif($_COOKIE['CheckValidation']!=md5(“your-password-here”).$pw->password) { // or if they’ve tried sneakily changing the CheckValidation cookie, say byebye!
echo “< p style='font-size:20pt;font-weight:bold;color:red;'>UNAUTHORISED COOKIE: You have tried logging in with an UNAUTHORISED cookie. You do not have permission to access this site!< / p>“;
exit();
}
}
And that’s how simple it is! Good luck! 
Related Posts:
When it is driven, just copy and paste the produced text file into your choice of text editor.
