Stop Spoofed Form Submissions

Question

I have a question about stopping spoofed form submissions. How about if by using the $_SERVER[\'HTTP_REFERER\'] I only allow submissions to my forms coming from

Answer 1

A suggestion would be to use a token. If you are using any of the popular MVC architectures, you do not need to worry as spoofing prevention is taken care of. But if you are on a custom MVC Architecture like myself, a token is an approach. In your Database class, for every CRUD(CREATE, READ, UPDATE AND DELETE) function, check for the token. e.g the token can be generated via md5.

public function save(){
if(isset($_SESSION['token']){
//proceed with saving
}else{
//kill it,
die;
}
}

Alternatively, you can easily integrate your web application with this Cross-Site Request Forgery protection kit. Check it out here

Answer 2

Let us be clear: it's technically impossible to prevent spoofed form submissions. Summing it up in one sentence:

If your browser can do it, everyone can do it.

Answer 3

The referrer is easily spoofed.

You should validate the form best you can to catch out stupid bots, and possibly use a server side CAPTCHA.

Answer 4

The main issues with form spoofing is that you don’t have any control over what the client sends. The user could change any form parameter. So everything the client sends on form submission needs to be validated and verified.

This also means, the less parameters you provide to be send in the form, the less you need to validate and verify. Particularly parameters that are preset and not to be changed by the user (i. e. hidden form fields) don’t need to be embedded into the form if not really necessary. Instead you could store them in a container in the session and only refer to this container via a hidden field. If this is not an option, make sure that you at least can detect any integrity flaw by singing the preset values with a MAC.

Another issue is that the form parameters that need to be send for a successful form submission are quite predictable so that an attacker could send repeatedly valid form submissions. If you would require a non-predictable parameter that can only be issued by your server and is validated on form submission, you could verify that the form submission is granted.

One solution would be to use a random one-time token that is generated on form request and is stored in the session as well as put into the form as a hidden input field. Then on form submission you check if a token was provided and whether it is equal to the one stored in the session; if they are equal, the you remove the token from the session and process the form, otherwise you deny the form processing.

Frankly, this mechanism is not perfect as you could still request the form first and then send a spoofed form data. That’s where you could use additional Captchas or other mechanisms that prevent automatic requests.

The best would be to use a combination of all measures mentioned above:

• create a form container in the session with a sufficiently random identifier; put that identifier as a hidden input field in the form to identify the form container on form submission
• store any preset parameters in the form container instead of the form
• if preset parameters cannot be excluded from the form, authenticate its value with a MAC (use a per form container key)
• if there are suspiciously repeated form requests/form submissions, think of additionally using Captchas to prevent automatic requests

Additionally, these session based form containers do also prevent CSRF as their identifiers are unpredictable for an attacking third party.

Answer 5

Stop? No. Limit? Possibly. Is your website really being hit with an alarming number of spoofed form submissions, or are you just being preemptive? Don't solve problems that aren't there.