Page 1 of 1
When HTTP_REFERER doesnt work & interpreting HTTP_USER_A
Posted: Wed Sep 06, 2006 12:34 pm
by fgomez
Hello,
I wrote a script to handle a form submission and thought I'd cleverly prevent hackers and spammers from abusing it using $_SERVER[HTTP_REFERER]. It goes a little something like this:
Code: Select all
$here = 'http://'.$_SERVER['HTTP_HOST'].dirname($_SERVER['PHP_SELF']).'/' ;
if($_POST['submit'] && !ereg('^'.$here.'.*$', $_SERVER[HTTP_REFERER])) {
/*output error message and log error*/;
} else {
/*submit the form*/
}
That works fine for preventing form abuse, as the form is self-submitting and submissions to it from any other referer are refused. However, I later learned it also prevents some legitimate users from submitting the form. Here's a little snippet from the manual:
HTTP_REFERER: The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
See it here:
http://us2.php.net/manual/en/reserved.variables.php
So my logging mechanism gets $_SERVER[HTTP_USER_AGENT] from the user because I want to know what browsers people are using that are causing the error. So far I've gotten just one (the logging feature is new), but I don't know what in tarnation it means:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts; .NET CLR 1.1.4322)
Can anyone decipher that? Does anyone know if there is a list somewhere of browsers that don't support HTTP_REFERER?
OK, and lastly... I guess best practice would be to stop using HTTP_REFERER for this purpose. Does anyone have a favorite way of preventing their forms from being duped?
Thanks!
Posted: Wed Sep 06, 2006 2:27 pm
by Mordred
What exatly do you mean by 'duped' and 'abusing'?
There is no way you can stop a bot from submitting data to you, unless you implement a really exotic CAPTCHA. You may try cookies, but even wget can handle that. You can try challenge/response with a hidden form field, but the bot can simply request the form each time and know the proper response.
Whatever a user can do a (determined) bot can mimic (besides the aforementioned exotic CAPTCHA

)
Btw I strongly suggest you use error_reporting(E_ALL) while developing. It's not $_SERVER[HTTP_REFERER], but $_SERVER['HTTP_REFERER']
Posted: Wed Sep 06, 2006 2:39 pm
by fgomez
Hmm... $_SERVER[HTTP_REFERER] works fine for me. Why is this wrong? I think in some cases I get a "T_ENCAPSED in whitespace" something or other error if I do use the quotes. It seemed strange to me that the quotes should in some cases be necessary, and in others not. If you know of a resource I should look at I'd appreciate it.
What I mean by abusing the form is submitting nonsense. Granted, my solution doesn't stop the form from being submitted, but it does stop the data from being recorded, or the email from being sent, as the case may be. In the past I've set up forms to send emails, only to find that bots were using them to send spam, or that someone had set up a form somewhere else and pointed their form action to the file that sits on my server.
Posted: Wed Sep 06, 2006 2:43 pm
by Luke
like he said... if you set your error reporting to E_ALL you would see errors ALL the time when omitting the quotes. They throw a warning a believe. There are different levels of errors that can be thrown. Only fatal errors stop script execution I'm pretty sure. Others let you know you messed up, but try to go on.
If you validate the information submitted to your form script it shouldn't matter where it came from... generally if its a spammer or something, it won't pass any decent validation process
Posted: Wed Sep 06, 2006 2:56 pm
by fgomez
Thanks for your input. Anyone know how to decipher the HTTP_USER_AGENT result? It was the second part of my question. Thanks!
Posted: Wed Sep 06, 2006 3:10 pm
by Luke
A quick search of Google told me that FunWebProducts is a company that creates adware applications:
http://www.google.com/search?q=FunWebPr ... S:official
Posted: Wed Sep 06, 2006 3:20 pm
by feyd
Posted: Wed Sep 06, 2006 3:28 pm
by Mordred
fgomez wrote:What I mean by abusing the form is submitting nonsense.
Ah, I get it now. But you see, users can submit nonsense too! It is your job to set strict rules on what constitutes "sense" and to apply your code only to "sensible" input, and just ignore all other (or - better - give an error, so the idi.. the user would know what went wrong)
Note that you should do whitelisting, i.e. define what is valid input and consider everything else invalid, as opposed to blacklisting, that is to check and reject just several options and accept anything else.
The user agent format is defined in the relevant RFCs for HTTP, but wikipedia and google may be easier for you
http://en.wikipedia.org/wiki/User_agent
http://www.google.com/search?q=user+agent+format
Posted: Wed Sep 06, 2006 4:22 pm
by fgomez
Ah, well I do have pretty decent (PHP) form validation in place already... I guess I am just overly paranoid with the HTTP_REFERER bit. Maybe I'll just comment it out and see whether the bots have a field day or not.
Regarding get_browser() and error_reporting(E_ALL).... Does error_reporting(E_ALL) work just by adding that line anywhere in the script?
Also, get_browser comes with a catch (from the manual):
Note: In order for this to work, your browscap configuration setting in php.ini must point to the correct location of the browscap.ini file on your system.
To date I've been able to avoid messing with my ini files. Generally speaking, are these the type of changes I can make myself, or will I have to ask the server admin to make them?
Thanks again.
Posted: Wed Sep 06, 2006 4:40 pm
by feyd
fgomez wrote:Does error_reporting(E_ALL) work just by adding that line anywhere in the script?
It affects code from that point forward.
fgomez wrote:Also, get_browser comes with a catch (from the manual):
Note: In order for this to work, your browscap configuration setting in php.ini must point to the correct location of the browscap.ini file on your system.
To date I've been able to avoid messing with my ini files. Generally speaking, are these the type of changes I can make myself, or will I have to ask the server admin to make them?
It's not much of a snag. If your host is unable or unwilling to change the ini to add support for this function, you can use a pure PHP version of it that I've posted previously.
search.php?search_keywords=feyd_get_browser