Comments on: Prevent form post request from another domain in PHP

By: Ihor Filakhtov

Ihor Filakhtov — Sat, 05 Dec 2009 14:16:58 +0000

This is bad idea…
Someone can use hiding HTTP-referer function, or can use another PHP-script to set fake-referer.

By: Adeel

Adeel — Mon, 12 Oct 2009 01:02:02 +0000

hello,

do web hosting have some kind of security that they prevent the posting from other domain?

like i have a web hosting and url is http://somedomain.com/mypage.php

now if someone trying to post the data form http://someotherdomain.com

will web hosting stop that post ? or i can able to receive it?

thank you

By: Sam IT

Sam IT — Tue, 22 Sep 2009 02:17:54 +0000

First of all, there’s no point to fight over 100% or 0%, there’s no 100% way to prevent spam. If your browser can view the page and submit a valid form so can they.

I think the programmer should do everything he/she can to prevent it.

Referrer check COULD and will help against some spammers.

So does a cookie/session, I would just add a key to the session on the same page in which the form is displayed to make sure the form was actually displayed then check if it exists on submit. Pretty simple and useful!

By: griffin

griffin — Thu, 26 Feb 2009 06:40:04 +0000

Misleading post. A very dangerous and unprofessional advice. You must warn your readers in the post itself.

By: Oliver

Oliver — Sun, 21 Sep 2008 06:55:59 +0000

captcha is one extra thing the visitor has to do. it goes against the basics of user experience to require them to fill in a field that has nothing to do with what they’re actually trying to achieve.

By: Joe

Joe — Mon, 21 Jul 2008 16:13:30 +0000

Why don’t you guys use image captcha? this concept has been used since the year 2000 to protect automatic post or bruteforce attack, even this comment form i’m posting right now is using captcha spam protection. but it is text based captcha wont achieve 100% protection.

By: Roshan

Roshan — Thu, 03 Jul 2008 16:44:39 +0000

@Joost – All the best for the developing full proof soloution for token alternator and hope to get the good soultion against session fixation…

if you find the better solution don’t forget to post that here as well..

By: Joost Pluijmers

Joost Pluijmers — Thu, 03 Jul 2008 14:32:06 +0000

Iam currently developing a fool proof token alternator. This means that within a set time frame a new token is generated for the site, how is this different? Because this token system won’t break the active sessions. Iam creating some sort of window algorithm for it, where within this window you get assigned a new token.

Iam planning to use this as a seed for HMAC, per-page keys and maybe even session id’s. This just guarantees several things:
- The request really comes from my domain.
- Nearly eliminates brute force attacks.
- Replay attacks will also be gone due to page-keys.

Now I just need to figure out a good solution against session fixation.

By: arty

arty — Wed, 02 Jul 2008 19:20:23 +0000

I also would suggest a pool of several tokens for a single user. If a user uses tabs he makes his old generated forms useless if you just overwrite your old token. So give the user about 5-10 tokens as max and delete them if they are used.

By: Joost Pluijmers

Joost Pluijmers — Wed, 25 Jun 2008 07:49:34 +0000

The best protection against form forgery is an appliance of HMAC. You know your going to serve a form, so why not put an encrypted token in an hidden field? When the form gets submitted you validate that against the token saved in the session for that user. Simple yet effective.

Using this method you can also expire the actual submitted form. So brute forcing the key will be useless as well.

The only real way this method gets cracked is if the users session id gets compromised.

By: Roshan

Roshan — Tue, 24 Jun 2008 18:46:23 +0000

Thanks tedivm and other friends for commenting…I’ll surely update date post with the best method

By: tedivm

tedivm — Tue, 24 Jun 2008 18:00:36 +0000

If an intruder already has the session id then its game over, they can steal that session. What your suggesting is the equivalent of stealing someones key but picking the lock anyways.

So lets think about this- how can the attacker get the session id? The easiest method would be to just sniff it, but that would require that they either be in the immediate area (in the case of wireless) or that they somehow break into a computer or router between the website your defending and the computer itself. Of course, both these methods are completely thwarted by a little thing called SSL.

Outside of that it gets a little more difficult, especially if some simple steps are taken in the program itself (tying the session id to an ip address and browser string, for instance).

In the future, before posting things like this, you may want to consider doing actual research. Most of the stuff I (and others) have brought up are pretty fundamental to PHP security and you could have easily found this information had you actually looked.

By: Roshan

Roshan — Tue, 24 Jun 2008 16:39:41 +0000

@tedivm – Ok I agree that your idea is somewhat ok but not 100% secure.Form name, session id , user name everything is visible to intruder. Do you think it is 100% secure ?

A intruder can easily view the source of the form see the name as well as he can look at the cookie to view the session id and guess the token with a few effort and with staying in that site he can easily post the value of token from a faked form…

By: tedivm

tedivm — Tue, 24 Jun 2008 09:05:28 +0000

Where did you hear that there was not a 100% reliable way of preventing cross site forgery? Did you bother doing any research at all before coming up with this post?

A rather simple way to prevent them is to require a posted variable (called a token) with each form that can’t be easily guessed by the site attempting the hack. A simple way to generate the token could be to create an md5 out of the session id and the form name (or the user name and form name).

By: Soren

Soren — Mon, 23 Jun 2008 21:23:22 +0000

Its trivial to send HTTP_REFERER for the spambot programs, so “not 100% reliable” is more like 0% reliable.

For real solutions, look at eg. the wikipedia page: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention