PHP form referrer security

Question

Possible Duplicate:
How to know where a form came from?

I was looking through these forums today but I couldn't find a good enough answer to my question.

How can I stop forms being submitted to my server unless they are referred from my domain. I have realised that if somebody just copies my form HTML directly and pastes it into their own platform, the data from their form will parse through my files and do what the form is set to do on my site.

How can I prevent this from happening? I was thinking of checking if the referrer is from my domain, but from what I have researched this wont prevent this from happening. So how can I stop this from happening?

Answer 1

REFERER is easily spoofed but is easy to check against so as a primary barrier of defense it is not too bad. For more sophisticated prevention, you could generate a token when the page with the form in question is loaded, store it in the user session, save it on a hidden field of the form, and when the form is submitted it check it against the session value. That can also be circumvented if someone wants to, though, so depending on what your specific case is HTTPS would then be the last resort.

Answer 2

There are two types of attacks that you might be trying to defend against.

A third party tricks a user into performing an action on your site

This is where Alice logs into Bob's website, then visits an attacker's website, and the attackers website causes Alice's browser to make (for example) a "transfer money" request to Bob's site.

This is a CSRF attack and the standard defence is to include, in a hidden field, a token that also exists in the user's session.

The attacker cannot get the token to put in their form, so you know the form is on your site if the tokens match.

A user modifies the data in the form to submit some data they really shouldn't

For example, Alice changes the POST_ID of a comment before submitting an Edit request and thus edits someone else's post, or perhaps she changes the price of goods being ordered.

The defence for this is to validate the input. If an edit request comes in, then make sure the logged in user has permission to edit the post. If an order comes in, then only pay attention to the items ids and quantities, you can get the prices from your database. etc.

Answer 3

You can't rely on the referrer! It can be disabled.

But you can use a token which you write a) in a hidden input field and b) into the user's session. And in your target script, you just check if they are equivalent!

Answer 4

You're trying to make sure that when a POST comes in to your application that it came from your server's FORM and not somewhere else. This is known as a Cross-Site Request Forgery (CSRF) attack.

Checking the referrer is problematic. First of all, the HTTP specification specifically allows for clients to not send referrer strings (for various privacy reasons). So, some of your clients may not include it. Second, referrer strings can be spoofed, where an attacker of sufficient skill can make them look like what they need to be in order to carry out a successful CSRF attack.

Using a CSRF validation token is a stronger approach and is the preferred method of mitigiation against CSRF attacks. You can read about why this is on the OWASP CSRF Cheat Sheet.

I will also point out that there is no reason why you cannot do both. A Defense-In-Depth (DiD) strategy is usually desirable, so that an attacker would need to defeat multiple, independent, defenses to execute a successful attack. You could implement a weak-referrer-checking approach (IF a referrer is provided by the client, make sure it is what it should be before acting on the request; if the referrer is not present, proceed as if it were present and correct) along with a CSRF validation token. That way, you check the referred information if the client provides it while still making use of the stronger validation token approach.