CAPTCHA with no $_SESSION

Due to the nature of the stateless behavior of HTTP, managing the current state of a connected user is a tricky scenario to handle in web site development or rather in web application development.

Few solutions are in place already and $_SESSION is one of the ways available in PHP. $_SESSION, the global array is not my favorite choice but it is handy. The sever based session management approach is not 100% reliable but it would do the work in most of the cases.

On the other hand, distinguishing user inputs versus inputs from malicious bots seems quite challenging these days. Simple tricks such as “honeypot” are quite old and easy to overcome, of course bots are now capable enough to skip “honeypots” without much effort. Then comes much promising solutions such as Google’s new invention, reCAPTCHA where a sophisticated techniques can identified the origin of the inputs blocking spams on your site, web application etc.

However life is not that easy, there are plenty of scenarios where we need to come up with our own strategy to deal with these inputs. If you cannot use reCAPTCHA or any other 3rd party CAPTCHA solution then the best would be implementing one of your own. This is the riskiest but there can be instances that this is the only way forward. I was in such a situation few months back and I though of sharing how I overcame it.

Avoiding $_SESSION

It is not hard to find plenty of tutorials to follow, implementing simple CAPTCHA verification in PHP. Almost every solution is based on $_SESSION, using server based sessions, a global array in PHP. This is easy and simple. Few lines of code would do the trick. As same as the way mentioned in this article. I am not a fan of server based sessions therefore I wanted to skip it.

In this post I am trying to explain how I solved the stateless issue without using server based sessions.

Breaking the Problem

The main issue that we need to solve is identifying the legitimate requests/ inputs and filter out the rest. In order to achieve this, when the relevant input form has been requested by a client, the server adds an image which is a human readable text. Bots may not be able to identify what is in it. Then the user inputs the code and sends the request to the server. As it is not possible to include the verification code in the client side request, the server doesn’t know what has been sent earlier. That is where server based sessions comes for the rescue. It is possible to store the verification code in a session variable.  Then when the user has submitted the form, the server can simply checks if the entered verification code value matches the value in the session. If so it is a human, test passes. Since we are trying to omit using server based sessions, we need to come up with a way to identify what has been sent earlier.

Solution

Step 1

Following is a typical code snippet (captcha.php) to create the CAPTCHA image. It is pretty straight forward and it can be seen that the verification code has been assigned to the session variable, $_SESSION[‘rand_code’] = $string;

<?php
session_start();

$string = '';

for ($i = 0; $i < 5; $i++) {     // this numbers refer to numbers of the ascii table (lower case)
$string .= chr(rand(97, 122)); }   
$_SESSION['rand_code'] = $string;   
$dir = 'fonts/';   
$image = imagecreatetruecolor(170, 60); 
$black = imagecolorallocate($image, 0, 0, 0); 
$color = imagecolorallocate($image, 200, 100, 90); // red 
$white = imagecolorallocate($image, 255, 255, 255);   imagefilledrectangle($image,0,0,399,99,$white); 
imagettftext ($image, 30, 0, 10, 40, $color, $dir."arial.ttf", $_SESSION['random_code']);   
header("Content-type: image/png"); 
imagepng($image); 
?>

Following shows how it has been included in the HTML, client side.

<form action="<?php echo $_SERVER['PHP_SELF']; ?>
" enctype="multipart/form-data" method="post"><input name="name" type="text" />

<input name="email" type="text" />

<textarea name="message"></textarea>

<img src="captcha.php" />

<input name="code" type="text" />

<input name="submit" type="reset" value="Send" />
</form>

When analyzing the HTML code, you will soon realize that the code can be exploited simply with a Cross Site Scripting (XSS) attack as it barely uses $_SERVER[‘PHP_SELF’] in form action. I will not be focusing on that since I am not going to use sessions here. Following is the modified prototype version.

Step 2

I have changed the client side code as follow. Notice that a hidden filed has been introduced. A randomly generated number with hash coded act as the reference id here. The reference has been passed when creating the CAPTCHA image and also it gets submitted when the user submits the form.

<?PHP
require_once 'dataBaseConnection.php';
<form action="verify.php" enctype="multipart/form-data" method="post">
Name: <input name="name" type="text" />

Email <input name="email" type="text" />

Message
<textarea name="message"></textarea>

<!--?PHP   $captchaId = sha1(rand(1000000,9999999).time());  dataBaseConnection::registerReference($captchaId);  $path='captcha.php?ref='.$captchaId;   ?--> <img src=""<?PHP" /> "/>
Enter the above code
<input name="c_id" type="hidden" value="<?PHP echo $captchaId; ?>" />

<input name="code" type="text" />

<input name="submit" type="submit" value="Send" />

and then the captcha.php has been modified too.

<?php
$string = '';
$refCode = '';

if(isset($_GET['ref']))
{
$refCode = $_GET['ref'];
}else{
die('<error>NO REF CODE FOUND !</error>');
}

for ($i = 0; $i < 8; $i++)
{
// this numbers refer to numbers of the ascii table (lower case)
$string .= chr(rand(97, 122));
}

$dir = 'fonts/';

$image = imagecreatetruecolor(170, 60);
$black = imagecolorallocate($image, 0, 0, 0);
$color = imagecolorallocate($image, 10, 10, 10); // red
$invColor = imagecolorallocate($image, 200, 200, 200); // invisible_ink
$white = imagecolorallocate($image, 255, 255, 255);

imagefilledrectangle($image,0,0,399,99,$white);
for($i=0; $i<100; $i++) 
{ 
imagettftext ($image, 20, rand(0,10), 0, $i*10, $invColor, $dir."ts.ttf", 'xxxxxxxxxxxxxxxxxxxxxxxxx'); 
} 
imagettftext ($image, 30, 2, 10, 40, $color, $dir."ts.ttf", $string);
header("Content-type: image/png"); 
imagepng($image); 
require_once 'dataBaseConnection.php'; dataBaseConnection::addVerificationCode($refCode, $string); //store the reference and the code in the database 
?>

The static methods dataBaseConnection::registerReference stores the reference code which will later be an input to captcha.php. The system automatically logs the timestamp and set the status of the record to ‘CREATED’. Then in the captcha.php file static method dataBaseConnection::addVerificationCode adds the generated verification code to the relevant reference .

Step 3

Then comes the verify.php code which validates the entered code against the code in the database.

<?php require_once 'dataBaseConnection.php'; if(isset($_POST['submit']))   {  	$enteredCode=trim($_POST['code']);  	$referenceCode=trim($_POST['c_id']);     $dataSet = dataBaseConnection::getCode($referenceCode);     $timeTaken = time() - $dataSet['pvt_created_date'];     if($timeTaken>$dataSet['pvt_life_time'] || $dataSet['pvt_captcha_status']!='CREATED')
    {
    	die('expired code');
    }

    //var_dump($referenceCode); die($enteredCode);
	if($enteredCode==$dataSet['str_verification_code'])
	{
		dataBaseConnection::updateCode($referenceCode,'VERIFIED');
		echo 'verified';//this is a human
		//Process the input as this is a legit request
	}else{
		dataBaseConnection::updateCode($referenceCode);
		echo 'not verified';//most probably not a human
	}
}
?>

If both codes match then the static method dataBaseConnection::updateCode changes the status of the verification code to ‘VERIFIED’ in the database while the status has been set to ‘USED’ for the verification code if they dont match. That expires the verification code and it will not be possible to use it again. Further there is a check to make sure that the code has not been expired too.

How secure this is

It is not difficult to train a bot to reading CAPTCHAs. Therefore to make this much stronger it is required to have an image with higher entropy.

Another weak point is, the reference code is getting exposed to the attacker. However there reference number has no relationship with the code. Therefore the attacker cannot predict the code by cracking the reference code. This is possible as we store the reference and the verification code in the database.

An attacker cannot use a brute force attack as the status of the verification code has been updated after an attempt has been made disregarding the results. So once tried the code is set to expired. Setting lifetime of the code can be used to limit the time available for the attacker to crack the image. In this case 300 seconds.

Further it is required to restrict direct access to captcha.php file from the outside, simply using .htaccess entry. Otherwise it is possible to carry out a Denial-of-service attack targeting the generation of the captcha image which in return could have lead to a database failure.

It is important to track client details but will discuss it in another post.

Conclusion

How to implement a captcha verification solution without using server based sessions has been discussed above. Complete source code can be found here. Please check it out and let me know any flaws you observe. This is a mere implementation of the concept and no other aspects were considered when developing the code and no proper testing has been carried out. Therefore if you are going to use it in your code please be careful unless you know what you are doing.