WorxWare

About five years ago, one of our clients contacted us about a project to minimize spam generated from their Feedback and Contact Us forms on their site. Not only were they getting more than 500 spam emails daily from the forms, but the forms were also being used to relay spam to large mailing lists showing the client as the sender.

This wasn't the first time we had been contracted to solve this type of problem.

It is rare to see a website without a form. Forms are the life-blood between your presence on the web and the prospects and clients that you want to interact with. Forms provide you with the data that makes or breaks your business. Forms can be used to collect user information. Examples are:

• Contact Us
• Feedback system
• Surveys

Forms can also be used to populate your databases. Examples are:

• Registration/Sign-up
• Data input of all types
• E-commerce

In the first set, collecting user information, the data collected is typically sent by email to the designated recipient, usually you or someone you appoint to get these types of info. emails. The forms require security to prevent hi-jacking of your form to deliver the hacker's email payload using your bandwidth and your identity.

In the second set, populating your database, the data collected is typically posted directly to the database. You may have a verification process where new accounts need to be approved before being live, but essentially the process is to take the user data typed in the form and post it directly to a database. These forms are particularly dangerous because a hacker can use the form to gain access to your entire database.

Back to the five year old project ... using a variety of techniques, we were able to eliminate almost 100% of all the hacks and spam emails. This hasn't been easy and we've changed strategies over time.

Our initial efforts were based on Javascript to both validate and format the data. That eliminated about 50% of all the emails. In analyzing why the Javascript was only 50% effective, we found that most hackers were already familiar with client-side validation. Using browser techniques, they launched the form, and then disabled Javascript to bypass the validation.

We then combined the Javascript validation (client-side validation) with server-side validation. Over a period of about 8 months refinining this technique, we were able to nearly eliminate 100% of the garbage emails.

That was four years ago. Since then we have changed our server-side validation several times using third-party scripts with some modifications from us. That was our proof of concept -- server-side validation works. To date, no one has been able to get past the server-side validation.

The first server-side validation script we used was the proof we needed that this technology is a must-have. Only one problem, though, is that third-party scripts typically are designed around the author's needs and not very flexible. Such was the case with the first server-side script we used. The validation rules were all based on some very rigid needs of the author, plus was tied to a templating system that forced a very rigid style of form design. For example, the templating system isn't able to handle multi-column forms, or radio buttons / check boxes horizontally. Plus, validation error messages were rigid in how they displayed.

Our second choice for server-side validation was newer technology and based on a more flexible templating system. It was closer to our needs -- but it lacked in validation rules and validation error messages were cryptic.

We have now totally eliminated client-side validation. The hacker's work-arounds for javascript based validation are too well known and client-side validation is now far far less effective rendering client-side validation as close to useless as possible.

We are also working on our our PHP-based server-side validation scripts that we expect to release as Open Source in 2011. If you have any feedback or features you would like to see, drop us a line.

Andy