The best idea here is as other stated, use CSRF tokens. The most simplest form is to add the users IP adress as a identifier in a database, and then add a random value for this IP. The random value is the correct token.
For example, when someone visit your page to get the form, take the users IP, lets say:
Add into a key-value database along with random value:
22.214.171.124 = ljghsdlghdlghdlshsdflgd (note, DONT use the example "ljghsdlghdlghdlshsdflgd", instead generate a pseudo-random value of a sufficent length)
Add this pseudo-random value as a hidden field.
On submit, use the users IP to look up the suggested reply. If the actual reply match the suggested reply, request is accepted.
On ANY attempt to submit (regardless of successful or not), delete the record in database, if any exist. This means any CSRF attempts will invalidate the real tokens for the targeted user, and each token will be one-use only. Depending on what type of database it is, its either simple as setting the key to "", or simply delete it.
126.96.36.199 = "".
A good idea is also to expire these values by time, both for security, but also to get rid of unneccessary data in the database. Depending on if its a forum, it can be wise to have a couple of hours as a validty time, while if its a simple form to lets say, change a password, then its enough with about 5 minutes as validity time.
Another idea is captcha, which also prevents automated client-side attacks, like virus infections and automated remote Control trojans. Depending on sensitivity of the web application, it can be a good idea to use Captcha AND CSRF-tokens in unison. Do not follow the advice to use the same token for a whole session, its a bad idea security-wise since theres a small possibility that the user might be tricked into submitting a token to a attacker aswell to the site. A single-use token will be wortless to the attacker, but a multi-use token can be as dangerous as a session, which CSRF is designed to protect.
So use single-use tokens, its the best security compared to multi-use tokens, ans also single-use tokens does not need to be protected in transit as the CSRF article in one of the other replies suggest.