A lot of people seem to have little idea of just what things they should be looking at when considering how to make the forms on their web page secure. Often the things they implement have nothing to do with security or possibly will prevent some types of attack while doing nothing to prevent an attack intended to fill their database with junk.
There are several things to consider with respect to security and the most important is one that seldom gets a mention in forums where people are asking about how to make their form more secure - validation. By validating each of the form fields on the server before doing anything else with that data you take care of about 90% or more of all the possible security issues and you ensure that the data being processed is at least reasonable content for the fields it has been entered in. Most form fields ought not to be able to contain the sorts of data that will cause any issues with security in the first place so by running validation on each field first thing on the server once the data gets there you immediately restrict any possible attack to those input fields where the characters they need to use for their attack are at least valid in that field.
The second thing you need to consider with security on the server is to keep the data completely separate from the code where ever possible. Modern databases allow you to specify the database command in one statement and the data that the command is to use in separate statements. Where separation is not possible because no command to keep them separate exists (as is the case when you are outputting data in HTML) then the data needs to be escaped so that it does not contain anything that can be confused as being code (in HTML escaping converts those characters to their entity code equivalents so that they can be displayed in the page rather than being interpreted as HTML). Note that this escaping is necessary on those data fields where characters that might be confused are allowed as valid data.
Between these two the security of most of the fields in the form is taken care of from when it gets to the server and we have not even had to implement any commands specific to security. Both of the two processes mentioned so far are needed to ensure that the data is processed properly and to notify legitimate users if they enter something that doesn't make sense.
The only form field that requires specific processing relating to security once it gets to the server are password fields. As with all the actual security measures that we implement the purpose is to protect the data entered into the form from being captured by a third party. There are several approaches that a third party could use to try to compromise the user data. An attack against the server itself cannot be prevented by any security that we implement on the form - that security is completely separate and is not relevant to the current topic except that if the server is compromised to the point where all the data is accessible then there is no security that you can implement on the form that will prevent access to that data. Whether the individual users passwords is known or not doesn't matter with respect to your site because all of the data that it is intended to protect is already compromised. Unfortunately a lot of people use the same password for multiple sites and so if their password becomes known by breaking into your server then it is possible that the discovered passwords could be used to break into individual accounts on other sites. It is to prevent this that we implement security on passwords - to protect our users if they have been silly enough to use the same password somewhere else. This security is normally applied by hashing the password - usually with some additional text that isn't entered by our user. Now for their original purpose of detecting if the content used to generate a hash has been changed, all hashes are equally secure since it is effectively impossible to change readable or executable content so that the content is changed and it still produces the same hash - thus allowing the change to be detected. Hashing of passwords though is different. By adding a known or server generated value to the password before hashing it we ensure that most of the possible alternate values that could be used to generate the same hash are eliminated. By hashing the password immediately upon receiving it on the server and only saving the hashed version (which can then be compared with the newly hashed value next time) we remove the need to have any limitations on what can be used as a password, and remove any need to validate or escape the password field. Because the password contains something that we generated as well as the user's password the hash value will also be completely different from any other site where the user has used the same password. That the password has been converted to a hash that is unique to this site means that there is nothing to indicate what their password is or whether they use it anywhere else.
Hashing a password by itself isn't enough though since there are only so many possible hashes and with sufficient computing power someone could simply keep trying possible passwords until they find one that works. To prevent a brute force attack like this and also to prevent someone flooding your site with information by filling out the form thousands or millions of times a second you do need to implement one additional security measure. You need to test for multiple submissions from the same address or trying to access the same account and time limit them. Just what time limits to apply depends on what the form is for but even if a person can copy and paste data into the form and has a legitimate reason for submitting it multiple times there would be at least a few seconds between each legitimate submission and so blocking any submissions from the same source that occur within say 10 to 30 seconds of the prior submission would be reasonable. Where there is a password involved you can also identify an account that is to be accessed and here you can take the further step of not only blocking any attempt that occurs too quickly after the prior attempt but also having that attempt reset the block time. You can even change the block period based on the number of invalid attempts. A five second block between the first three attempts will not significantly affect anyone who accidentally mistypes their password on their first attempt neither will a fifteen second delay between subsequent attempts since if they can't get it right in three goes they will probably have to look it up before trying a fourth time. These delays will have a huge impact on any attempt to break into the account by simply trying possible passwords since if the delay is allowed for then it would take too long and if the delay isn't allowed for it would require guessing right on the first attempt.
That takes care of security after the data gets to the server. It is possible for the data to be compromised before it gets that far though. For protection between the client computer and the server the data needs to be encrypted before it is sent and decrypted again once it is received. The only way to do this is to use SSL and a security certificate. That is the only way that protection can be applied during that part of the process.
With those measures in place the only area left where the form can be compromised is on the user's computer itself before they send it. Here you have no control whatsoever. There is nothing that you can do that will affect the security of the form prior to the data leaving their computer. The security at that point relies on their having appropriate anti-spyware/keylogger software installed that will hopefully prevent anyone installing anything onto their computer that will give a third party access to what they enter in any form.
This article written by Stephen Chapman, Felgall Pty Ltd.