Some ideas to tighten up form script security … more specifically to counter form spoofing and cross browser attacks.

(1) Check for extra _POST variables, and disallow any _GET variables.

{
$limit_post=count($_POST);
$limit_get=count($_GET);
if ($limit_post>8||$limit_get>0)
{
include (”formhead.php”);
echo “Submission failed.”;
include (”form2.php”);
exit;
}
}

(2) Prevent the exceeding of maximum field length from the server side in the script - setting form field maximum length inputs is not sufficient.

{
$length = strlen($_POST[’Name’] || $_POST[’Email’] || $_POST[’Address’] || etc);
if($length>30)
{
include (”formhead.php”);
echo “Too many characters.”;
include (”form2.php”);
exit;
}
}

(3) Check for legal use of characters (white list approach).

{
if (eregi(”[^-a-z]+$”, $_POST[’Name’]) || eregi(”[^-/\.a-z0-9]+$”, $_POST[’Address’]) || eregi(”[^-a-z]+$”, $_POST[’City’]) etc)
{
include (”formhead.php”);
echo “Invalid characters.”;
include (”form2.php”);
exit;
}
}

(4) Check for well-formed email address.

{
if (!eregi(”^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*$”, $_POST[’Email’]))
{
include (”formhead.php”);
echo “Please enter a valid email.”;
$_POST[’Email’]=”";
include (”form2.php”);
exit;
}
}

(5) Use quotemeta to filter output (note that quotemeta doesn’t filter the pipe character - hence the productiveness of using the previous eregi function).

(6) Use the Session token method described at http://shiflett.org/archive/96 to further prevent XSS attacks.

eg.

In the document head:

<?php $token = md5(uniqid(rand(), true));
$_SESSION[’token’] = $token; ?>

In the form:

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

In the script:

{
if ($_SESSION[’token’] != $_POST[’token’])
{
echo “Invalid submission.”;
//go to error page
exit;
}
}

References:

http://phpsec.org/projects/guide/2.html
http://www.devshed.com/c/a/PHP/Reconsidering-PHP-variables/
http://au.php.net/manual/en/function.quotemeta.php
http://shiflett.org/

Spammers, the dregs of the internet, are now using automated bots to explore form security.

The bot completes the form to test for possible usage as a spam relay, attempting to inject extra headers which, if successful, will send the response to the bot owner.

To counter their tactics, fields like the mailto, from and subject fields can be checked server side (all user input should be checked server side).

eg.

mailto:

$to=$mailTo;
if ($to !== “youraddy@yourdomain.com”)
{
die(”Getawoollyoneupyah, spammer!”);
}

from and subject fields:

if ((preg_match(' /[\r\n,;\'"]/ ', $_POST['Email'])) || (preg_match(' /[\r\n,;\'"]/ ', $mailSubject)))
{
die(”Go away, spammer!”);
}

Then, to prevent the bot filling in the form at all, the contact name field for example, can be checked as the bot attempts to fill in all fields with an email address.

elseif (eregi("[^-a-z ]", $_POST[Name]))
{
echo “Characters in name field are invalid.”;
$_POST[Name] =”";
}

More information about the relevant email injection exploit can be found here:

http://computerbookshelf.com/email_injection/
http://securephp.damonkohler.com/index.php/Email_Injection

There’s a form testing script linked here as well as an explanation re asp scripts:

http://www.twologs.com/en/services/test/spamrelay.asp

and a script to ban known spam bots here:

http://www.foto50.com/spammercheck.phps