The Website Change Request Form has been a running topic around here for a little while and I’m gonna run with that for a little while. We are not going to rehash all the HTML and JavaScript that makes the form work, so if you need to catch up, go check out that first article.

What we have at this point is a pretty nice looking form that has a pretty nice user experience to it. I feel like it’s lacking two major things though. A) the notification emails themselves are pretty bland and basic text emails and B) there is almost no security at all on the form itself.

Thanks to Daniel Friedrich, I know have implemented some more serious security into the form and that will be the focus of this article. The two big goals are:

• The form is being submitted by a human being
• That human being isn’t doing anything nefarious

Token Matching

The first thing that we are going to do is generate a “token”, essentially a secret code. This token is going to be part of our “session”, meaning it is stored server side. This token also is going to be applied as a hidden input on the form itself when it is first generated in the browser. That means this token exists both on the client side and the server side and we can match them when the form gets submitted and make sure they are the same. What this does is ensure that any submission of the form is our form and not some third-party script wailing away at us from a different server.

First we’ll need to start a session, then create a function to build the token, apply it to the session, and return it for our use.

session_start();

function generateFormToken($form) {
    
       // generate a token from an unique value
    	$token = md5(uniqid(microtime(), true));  
    	
    	// Write the generated token to the session variable to check it against the hidden field when the form is sent
    	$_SESSION[$form.'_token'] = $token; 
    	
    	return $token;

}

The unique value here comes from a md5 hash of the microtime function, but Daniel says there are a slew of other crypting methods (like salt-values…). Now that we have this function, right before we build the form in the markup we can call it to create the value.

<?php
   // generate a new token for the $_SESSION superglobal and put them in a hidden field
   $newToken = generateFormToken('form1');   
?>

Then put the token as a hidden input into the form itself:

<input name="token" type="hidden" value="<?php echo $newToken; ?>">

Now we are prepared to check the token values against each other when the form is submitted. We’ll create a function to do that.

function verifyFormToken($form) {
  // check if a session is started and a token is transmitted, if not return an error
  if (!isset($_SESSION[$form.'_token'])) { 
    return false;
  }
	
  // check if the form is sent with token in it
  if (!isset($_POST['token'])) {
    return false;
  }
	
  // compare the tokens against each other if they are still the same
  if ($_SESSION[$form.'_token'] !== $_POST['token']) {
    return false;
  }
	
  return true;
}

This function checks to see if the token exists in both required places and that they match. If all those three things are true, the function returns true, if not, it returns false. Now we check that value before proceeding. The basic structure is:

if (verifyFormToken('form1')) {

   // ... more security testing
   // if pass, send email

} else {
   
   echo "Hack-Attempt detected. Got ya!.";
   writeLog('Formtoken');

}

Hack Logging

Notice in the structure above we use a function called writeLog() that takes a string. There are a variety of circumstances in which we have detected foul play and need to stop. In those cases we will call the writeLog() function to log the error for our own reference and then die()

This function attempts to write to a text file on the server (that file is going to need proper file permissions, user writeable) or if that fails, it will email it to you.

function writeLog($where) {

	$ip = $_SERVER["REMOTE_ADDR"]; // Get the IP from superglobal
	$host = gethostbyaddr($ip);    // Try to locate the host of the attack
	$date = date("d M Y");
	
	// create a logging message with php heredoc syntax
	$logging = <<<LOG
		\n
		<< Start of Message >>
		There was a hacking attempt on your form. \n 
		Date of Attack: {$date}
		IP-Adress: {$ip} \n
		Host of Attacker: {$host}
		Point of Attack: {$where}
		<< End of Message >>
LOG;
        
        // open log file
		if($handle = fopen('hacklog.log', 'a')) {
		
			fputs($handle, $logging);  // write the Data to file
			fclose($handle);           // close the file
			
		} else {  // if first method is not working, for example because of wrong file permissions, email the data
		
        	$to = '[email protected]';  
        	$subject = 'HACK ATTEMPT';
        	$header = 'From: [email protected]';
        	if (mail($to, $subject, $logging, $header)) {
        		echo "Sent notice to admin.";
        	}

	}
}

Nothing POSTED we didn’t ask for

If any values get posted to us that don’t have names from inputs in our own form, something funky is definitely going on. We’ll build a “whitelist” of acceptable post names and then check each one.

// Building a whitelist array with keys which will send through the form, no others would be accepted later on
$whitelist = array('token','req-name','req-email','typeOfChange','urgency','URL-main','addURLS', 'curText', 'newText', 'save-stuff');

// Building an array with the $_POST-superglobal 
foreach ($_POST as $key=>$item) { 
  // Check if the value $key (fieldname from $_POST) can be found in the whitelisting array, if not, die with a short message to the hacker
  if (!in_array($key, $whitelist)) {
			
    writeLog('Unknown form fields');
    ie("Hack-Attempt detected. Please use only the fields in the form");
			
  }
}

Valid URL

The client-side validation on this form watches for this, so it should be caught up front, but of course we should be checking on the back end too.

// Lets check the URL whether it's a real URL or not. if not, stop the script
if (!filter_var($_POST['URL-main'],FILTER_VALIDATE_URL)) {
   writeLog('URL Validation');
   die('Please insert a valid URL');
}

Cleaning values

At this point we have made all our security checks and are proceeding to create and send the email. Taking all the inputs exactly as entered and sending them on is a potential security risk. For example, JavaScript could be entered in a text field and then sent over email and potentially ran when the email is opened.

For the fields like “Name”, where there is no reason to use any special tags, we will strip them entirely with strip_tags(). For the textareas, where there may be occasion to use some tags, we’ll just the htmlentities() function to convert them safely.

Example:

$message .= "Name: " . strip_tags($_POST['req-name']) . "\n";

$message .= "NEW Content: " . htmlentities($_POST['newText']) . "\n";

More Better Cleaning

Krinkle writes in to say:

Originally you used strip_tags() for normal fields and htmlentities() for content. This is fine, except that it’s best practice to declare ENT_NOQUOTES and “UTF-8″ as well, since otherwise characters like the accent on the e (” é “) could become crap like Å@. And since most servers add slashes to input brought via $_POST[] it’s not a bad thing to run stripslashes just in case, else you’d have a slash in front of every single or doublequote that was typed entered in the form once it’s in the mailbox.

function stripcleantohtml($s){
  // Restores the added slashes (ie.: " I\'m John " for security in output, and escapes them in htmlentities(ie.:  " etc.)
  // Also strips any <html> tags it may encounter
  // Use: Anything that shouldn't contain html (pretty much everything that is not a textarea)
  return htmlentities(trim(strip_tags(stripslashes($s)), ENT_NOQUOTES, "UTF-8"));
}

function cleantohtml($s){
  // Restores the added slashes (ie.: " I\'m John " for security in output, and escapes them in htmlentities(ie.:  " etc.)
  // It preserves any <html> tags in that they are encoded aswell (like <html>)
  // As an extra security, if people would try to inject tags that would become tags after stripping away bad characters,
  // we do still strip tags but only after htmlentities, so any genuine code examples will stay
  // Use: For input fields that may contain html, like a textarea
  return strip_tags(htmlentities(trim(stripslashes($s)), ENT_NOQUOTES, "UTF-8"));
}

Usage in this example:

$message .= "Name: " . stripcleantohtml($_POST['req-name']) . "\n";

$message .= "NEW Content: " . cleantohtml($_POST['newText']) . "\n";

Why not use a CAPTCHA?

CAPTCHAs do a fairly good job of keeping spam off of forms, but we were worried more about hacking here than spam. Also, since this form is for people that we probably LIKE and are trying to HELP, we aren’t going to put them through the annoying hoop-jumping of a CAPTCHA. However, if you are interested, a super-duper simple home-brew captcha is to ask something like “What is ten minus five?” in a text input and then check for the values “5” and any capital letter combination of “five” and if it’s a match then continue, if not, don’t. This version of the form already has writeLog() function which is ready to use just for this, and the logic would fit in nicely around lines 75 and 76.

If you’d like a little more robust CAPTCHA, check out reCAPTCHA, which is pretty easy to use, helps people, and is very accessible.

Security Gurus?

When we talk about security around here, there tends to be a lot of opinions on how things are being done. If you have ideas, please share them below as constructively as you can, and I’ll be digesting and seeing how we can improve as we go along.

View Demo Download Files