Thursday, March 12, 2009

Combating Spam (part 4 of 6)

... Client-side Validation continued ...
Empty Spaces

This should go without saying. If you have empty fields, the form should not be submitted, and an error should be displayed. You don’t want empty data being sent to your mail now do you? Sometimes empty email is far worse than those persistent Viagra ads. With the latter, at least you have something to read and curse at. ;-)

You could create a class called “required” and assign it to all fields that require data. Then validate and check all “required” fields for empty data. Keep in mind “empty” data could mean many things. It could mean a null value, an empty string, single space or series of spaces, or even a carriage return. You should test for all these conditions.

Testing for empty spaces is also a great way to promote data integrity, especially if you are collecting information and storing it in a database.


Phone Number

Usually people don’t like entering phone numbers into contact forms. If you require this information, then you better validate the field so that, at the very least, you don’t get random letters and numbers.

Checking for valid phone numbers not only prevents garbage text from being entered, it is also another way to slow spammers down, if only for a little bit. It also forces persistent spambot programmers to adapt their code.

... generally spammers and hackers are kind of lazy. They like to do as little as possible with the highest possible gain. So, rewriting spambot programming is not always in their best interest. They would rather take advantage of people who are careless enough to leave the back door open...

Make sure your phone numbers are in the format of ten digits, including area code.

TIP: A common practice for user friendliness is to separate a phone number into three fields and auto-jump to the next field. A hidden field can be used to concatenate the values for easy validation.


Postal Code

Much like the validation for a phone number, correct syntax will slow spammers down. This really aggravates them because they don’t care about entering postal codes. The great thing about the World Wide Web is that it is all one big postal code! An e-mail address is an e-mail address regardless of where you live.

Having to enter letter-number-letter-number-letter-number is really annoying, even for regular users. Therefore, by forcing spammers and spambots to do this, you are cutting down on invalid data as well as trimming the spam.

Canadian postal codes must be in the format T0T 0T0.


E-mail

E-mail validation is fairly important because you want to ensure your visitors leave a valid return address of their choosing. Usually people don’t want you to reply to the e-mail address provided by their web server. Furthermore, you want to annoy your spammers by entering valid data.

Hey, it’s not like a spammer or spambot is going to leave you a return address so that you can exchange in witty banter. But, at least you have fired one more torpedo at the little buggers.

This field must be in the correct format of having a minimum of one “@” and one “.” Furthermore, the “@” must not be the first character, and the “.” must not be the last character. This is a simple check to do, and goes a long way.

Part 3
Part 2
Part 1

Labels: , ,

Tuesday, March 10, 2009

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

Labels: , , ,

Friday, March 6, 2009

Combating Spam (part 2 of 6)

Harsh Reality

Before you enter the battle zone you have to acknowledge a fundamental truth and accept a harsh reality:

There is no 100% sure-fire way to blow spam out of the water!

You can launch as many torpedoes at it as you want, but somehow it will manage to crawl out of its charred cesspool and find its way back to you. This reminds me of a song and a cute animation of a very persistent cat. “… I thought he was a goner, but the cat came back... the very next day...”

Unfortunately there is nothing cute about e-mail SPAM. It is at best, irritating, and in my opinion, the bane of the internet.

Ultimately though, the more torpedoes you launch at spam the farther you will send it, consequently taking it longer for it to make its way back to your inbox. I make all this sound like a war of epic proportions, when it's more akin to a plague that you try to keep from entering your house. From a developer's standpoint, it’s almost like a game of chess, where you have to think a few steps ahead of your opponent. You have to think like a spammer and figure out ways to counteract any attempts to exploit the weaknesses of your contact forms.

The bottom line is, the more combinations of spam-eliminating strategies you utilize, the longer you will live a spam-free diet. You have to realize that programming automated spam isn't that difficult. In most cases spammers rely on ignorance and laziness of the common internet user. The same goes for developers. Ignorance is NOT bliss. To truly be spam-free you must employ a comprehensive two-pronged approach:

Client-side Validation and Server-side Validation.

Part 1

Labels: , , ,

Tuesday, March 3, 2009

Combating Spam (part 1 of 6)

Bad Taste in Your Mouth

Are you sick and tired of SPAM?

No I’m not talking about the processed puke in a can. I’m talking about the bane of the Internet, e-mail SPAM.

I’m sure you, like billions more around the world, get a little queasy every time you open your inbox. You cross your fingers and hope you don’t have to look at another Viagra or penis enlargement ad.

Well thankfully, if you’re a web developer, there is a lot you can do to control, if not eliminate, 99%* of the spam in your inbox. But let’s be clear that we are talking about spam originating from vulnerabilities in your website’s contact form.

Aside from having spam filters on your mail server (which is a MUST), there are some very practical and well-known methods to trim the spam from your diet. There are some lesser-known (more effective) methods, which I cover as well.

After implementing most of the methods that I will divulge over the next few weeks, I was able to eliminate 99%* of the spam from my inbox, as well as the spam from our customers' inbox.

*Why 99%? If spammers know your email address, the only thing you can do is change your email address. Well, that, and stop visiting websites which contain questionable material. ;-)

Labels: , , ,