Verifying Form Input

Once you start using forms, you'll soon realize the need for verifying the data that your users enter into your form. At a minimum, you'll want to make sure that all users fill in certain fields that you consider to be required. You'll want to make sure that they only enter digits into a field in which they're supposed to enter their age. It would be nice if input fields included attributes such as required="yes" or fieldtype="numeric" or things of this nature, but HTML does not include any attributes of this nature. In fact, HTML includes absolutely no facilities for verifying form data.

To verify form data, you'll need to use some sort of processing language. This can be done by the browser (client-side) using JavaScript (or in IE using VBScript). Or it can be done by the server-side program that receives the form data.

Client-side checking is the most user-friendly method. A JavaScript script can detect errors, and can pop up an alert box to the user telling him to enter proper data into a field. It can put the cursor right into the field that is in error, making it easy for the user to enter correct data.

Server-side checking is less user-friendly. If an error is detected, the server-side program has to send a new HTML page that includes an error message. The user has to use the back button to get back to the form in order to correct his input.

Since these pages are about HTML and not about JavaScript or server-side programming languages, I'm not going to show how you can go about doing form verification. However, I'll discuss a little bit about the types of things you'll want to consider.

Types of Errors

There are three types of errors you should think about when you use a form-based method to send data to a server-side program.

• Accidental errors
• Intentional non-malicious errors
• Malicious errors

Accidental Errors

For most of your users, you can expect only accidental errors. Your user may fail to fill in a required field, or may make a typing error or misunderstand what you wanted typed into a field. For these types of errors, client-side checking is quite adequate for the most part. The user will only manage to send incorrect data if he has disabled javascript or if he is using a browser that does not support javascript.

Intentional Non-Malicious Errors

A few of your users will intentionally enter incorrect data. They're probably just curious what will happen if they enter their age as 524 or as xyz instead of as a reasonable value. They may do things such as disabling javascript to see if they can sneak this bad data past your checks, but they're not trying to be really malicious.

Because these users may disable javascript, you can't count on client-side verification to catch these intentional errors. You'll need to catch these on the server side.

Malicious Errors

A much smaller percentage of users will have malicious intent. If you're lucky, you'll never get such a user at your site — but you can never be sure. I'm sure that you're aware of the number of viruses that have been set loose on the internet, so you can understand that there are people who do try to break into computer systems. Form-based server-side programs often provide security holes that these people try to take advantage of. Server-side verification is absolutely required to avoid these attacks.

Suppose, for example, that your form contains a radio button pair named "sex" for indicating whether the user is male or female. You might think that the only values you can receive are sex=male or sex=female, but this is not the case at all. Anyone can save your HTML page to their own hard drive and modify it to their heart's content. They could substitute a textarea named "sex" for the radio buttons, and send anything they want for that field. The received value could be hundreds of bytes long.

One trick a malicious user might use is to send HTML code (possibly including javascript code, java applets, or ActiveX components) as the value. Suppose your server-side program saves these values in a database and then displays it back to other users, as in a guestbook application. You could be sending this HTML code back to other users. ActiveX components, in particular, could do a lot of damage to your users.

Some server-side programs use form input data to form commands that the operating system of the server are to execute. For example, a server-side program running under Unix might form some Unix commands that are constructed from the form data. This type of processing is especially vulnerable to a malicious user, and can allow the user to compromise anything on the server — not just your own code running on the server. Users can gain access to the server's password file, for example. It is for this reason that many service providers don't provide CGI capabilities to their users.

Being able to deflect your malicious visitors is very important. When you get to the point where you're developing server-side applications of your own, you'll want to be sure and learn methods to prevent these sorts of attacks.