Combating Spam (part 3 of 6)

CLIENT-SIDE VALIDATION

You want to do as much client-side validation as possible before sending the data off to the server. Let the spammer’s machine do the legwork of validating everything, before you place a load on your server and eat up precious bandwidth.

This type of validation, if done correctly, can also enhance the user experience by providing contextual error checking. This means error messages appear exactly where the corresponding error occurred, and in this manner can provide more detail about the type of error.

Typical forms merely display a single error message and put red asterisks next to erroneous fields, without any information on why the field is incorrect. In some cases you have to hit the BACK button, forcing the server to re-POST the data. This not only puts unnecessary load on the server, it can sometimes result in loss of data. You know how the internet is. Furthermore, do you really want your users clicking back and forth if something is wrong?

With client-side validation you can do a lot of good and save yourself some headache. You are making your forms more accessible, promoting data integrity, reducing spam, reducing bandwidth, and overall, adding some extra value to your site.

The next section covers the most common client-side validations to perform.


Illegal Characters

If you only do ONE type of validation let it be this one! This alone will eliminate a lot of spam. Failure to comply will result in a very bloated spam-filled diet, possibly requiring therapy and counseling afterward.

The reason this is so vital is because the mail() command in PHP has a vulnerability which allows spammers to inject (add) extra headers. In other words, a spammer could add extra recipients, e-mail forwards, HTML code, and links to malicious websites. Smart hackers could even access your PHP files, leading to all sorts of nastiness that would make even Bill Gates cringe. Sound dangerous? Indeed.

Left unchecked, this kind of security hole can cause a lot of problems and misery. You must eliminate, scratch that, disallow these ILLEGAL characters from being entered into your input fields in the first place.

Check ALL input fields for illegal characters. Don’t just check the MESSAGE field. All fields are equally vulnerable, disregarding their maximum character length.

Below is a list of the curious character culprits in question.

%, \, <, >, www, http, /, php?, to:, cc:, bcc:

[ % ] - used for manual URL encoding
[ \ ] - used for things like \r \l \d which allow extra email headers. This is dangerous!
[ <, > ] - used for manually embedding HTML content
[ www ] - used for website links
[ http ] - used for website links
[ / ] - used for website links
[ php? ] - used for direct access to php pages; variable contents can be changed
[ to: ] - used for adding extra recipients
[ cc: ] - used for adding extra forwards
[ bcc: ] - ditto

Part 2
Part 1