Blank form processing: POST values lost?

dmcconkey

Hi folks,

I have a client with four websites. Each site has a contact form that
is identical. They all have "required" fields validated through a
JavaScript onSubmit() function. Upon validation, post values go to a
PHP processing page that adds values to a database and generates an
email to someone in marketing.

For three of these sites, we have no problem, but the fourth keeps
sending in blank forms.

I'd understand the occasional, JavaScript turned off + user
accidentally hitting submit without filling in any values. However,
this happens about 3% of the time (and only on one site). I'm worried
that $_POST values are somehow lost in the PHP processing page.

The relevant code in the processing page is:

$message = "";

foreach($_POST as $key=>$val)
{

$message .= "$key" . ": " . $val . "\n";
}

if( strlen( $message ) > 0 )
{
$to = "bo*@example.com";
$subject = "Contact Us Form Results";
$headers = "From: $to";
$send = mail( $to, $subject, $message, $headers );

if ( $send ) echo "success";
else echo "error";
}

I thought that maybe I have a robot somehow visiting this page directly
(without first going through the form), but the if( strlen( $message )

0 ) line should stop the email if message is blank.

To be thorough, I'll include the JavaScript validation code below.
field_arr = new Array( "name", "phone", ... );
field_desc_arr = new Array( "Name", "Telephone Number", ... );
for ( i = 0 ; i < field_arr.length ; i++ )
{
eval("field = passed_form." + field_arr[i] + ";");
if ( ( !field.value ) || ( field.value.length < 1 ) )
{
alert("You can't submit form without completing " + field_desc_arr[i]
+ "!\nPlease try again.");
field.focus();
field.select();
return(false);
}
}

Anyone see anything I might have missed?

Jul 17 '05 #1

Alvaro G Vicario

*** dm*******@yahoo.com wrote/escribió (14 Jun 2005 10:46:03 -0700):

To be thorough, I'll include the JavaScript validation code below. [...] Anyone see anything I might have missed?

Have you tested your form with any browser apart from Internet Explorer. If
JavaScript is critical to the application that'd be a good beginning.

Also, is it possible that visitors are accessing the form processing script
directly, maybe from another POST script you may have forgot about?
--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--

Jul 17 '05 #2

Alvaro G Vicario

*** Alvaro G Vicario wrote/escribió (Tue, 14 Jun 2005 21:00:03 +0200):

Have you tested your form with any browser apart from Internet Explorer. If
JavaScript is critical to the application that'd be a good beginning.

I forgot to mention: add debugging info to your form, especially $_POST,
$_SERVER['HTTP_REFERER'] and $_SERVER['USER_AGENT']. Functions like
var_dump() may be useful.

--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--

Jul 17 '05 #3

dmcconkey

Alvaro G Vicario wrote:

*** Alvaro G Vicario wrote/escribió (Tue, 14 Jun 2005 21:00:03 +0200):

Have you tested your form with any browser apart from Internet Explorer.. If
JavaScript is critical to the application that'd be a good beginning.

I forgot to mention: add debugging info to your form, especially $_POST,
$_SERVER['HTTP_REFERER'] and $_SERVER['USER_AGENT']. Functions like
var_dump() may be useful.

--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--

Thanks, Alvaro.

I have tested using IE6, FireFox, and Opera on Windows. FireFox and
Opera on Linux. I don't have an OSX Mac. (I've even tried it with Lynx,
though that was expected to bypass the validation.)

As far as the debug vars, I've recently added a $_SERVER dump into the
email line. Hopefully I can figure out that all of these have something
in common.

Getting to the processing page from a page other than the form was my
first guess. That's why I dumped the $_SERVER variable.

Does GoogleBot (or any other bot for that matter) identify itself
within the USER_AGENT string?

Again, thanks.

Jul 17 '05 #4

Gordon Burditt

>I have a client with four websites. Each site has a contact form that

is identical. They all have "required" fields validated through a
JavaScript onSubmit() function.
Remember, JavaScript does validation only if the client WANTS it
to do validation. Anyone else (especially the malicious ones, and
bots, and PHP pages getting the content of other pages, etc.) can
make their own form or request and leave out the JavaScript. Or
they can just turn it off.
Upon validation, post values go to a
PHP processing page that adds values to a database and generates an
email to someone in marketing.
I certainly hope the PHP processing page does at least enough
validation of its own to avoid SQL injection attacks. If I put the
last name O'Brien in the contact form, and it causes a SQL error,
you're in trouble.
For three of these sites, we have no problem, but the fourth keeps
sending in blank forms. I'd understand the occasional, JavaScript turned off + user
accidentally hitting submit without filling in any values. However,
this happens about 3% of the time (and only on one site). I'm worried
that $_POST values are somehow lost in the PHP processing page.
Have you considered detecting when this happens, and logging relevant
things, like $_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_REFERER'],
and $_SERVER['HTTP_USER_AGENT'] ? It might turn out to be a search
engine bot. Do reverse lookups on the IP addresses. Many bots
clearly identify themselves in HTTP_USER_AGENT.

Oh, yes, some of this info may be in your Apache logs already if
you can match up times the blank messages are sent.

The relevant code in the processing page is:

$message = "";

foreach($_POST as $key=>$val)
{

$message .= "$key" . ": " . $val . "\n";
}

if( strlen( $message ) > 0 )
{
$to = "bo*@example.com";
$subject = "Contact Us Form Results";
$headers = "From: $to";
$send = mail( $to, $subject, $message, $headers );

if ( $send ) echo "success";
else echo "error";
Are you getting blank messages *IN SPITE OF* the check above, or
did you put the check in because you kept getting blank messages?
If you are still getting blanks in spite of the check, that's wierd.}

I thought that maybe I have a robot somehow visiting this page directly
(without first going through the form), but the if( strlen( $message )

0 ) line should stop the email if message is blank.

I vaguely recall something about the behavior of array iteration
with superglobals being odd and different between PHP versions. I
can't remember what it was, though. Is the odd-site-out having
blank emails using a different PHP version from the others?

Gordon L. Burditt

Jul 17 '05 #5

dmcconkey

> I certainly hope the PHP processing page does at least enough

validation of its own to avoid SQL injection attacks. If I put the
last name O'Brien in the contact form, and it causes a SQL error,
you're in trouble.
I edit $_POST values via addslashes() and trim(). In other forms that
require numerical values or date/time entries, I use programming logic
to verify info. All is server-side. Not enough?
Have you considered detecting when this happens, and logging relevant
things, like $_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_REFERER'],
and $_SERVER['HTTP_USER_AGENT'] ?
This was brought to my attention this morning. I added a dump of the
$_SERVER array to the email. When I have more than a couple to look at,
I'll try to find a thread.
Are you getting blank messages *IN SPITE OF* the check above, or
did you put the check in because you kept getting blank messages?
If you are still getting blanks in spite of the check, that's wierd.
The check has been in since the beginning. That's primarilly what I
don't understand. In the resulting email, a healthy message might read
"first_name: John". In the errant messages, the line reads
"first_name:". Not even a space. (adding values to the database uses
trim(), but generating the email uses the raw post values). In the
$key=>$val clause, it would seem that $key is filled with the names of
my input fields but $val is null. Would $_POST have an element for a
given input field if the field were null?
I vaguely recall something about the behavior of array iteration
with superglobals being odd and different between PHP versions. I
can't remember what it was, though. Is the odd-site-out having
blank emails using a different PHP version from the others?

Great idea. Last I checked the odd site out was on the same box as two
of the others, and running PHP 4.

Thanks for the lead,
-Dan

Jul 17 '05 #6

Gordon Burditt

>> I certainly hope the PHP processing page does at least enough

validation of its own to avoid SQL injection attacks. If I put the
last name O'Brien in the contact form, and it causes a SQL error,
you're in trouble.
I edit $_POST values via addslashes() and trim(). In other forms that
require numerical values or date/time entries, I use programming logic
to verify info. All is server-side. Not enough?

That should be good enough. Too many people using JavaScript try
to do their input validation EXCLUSIVELY in JavaScript. But watch
out for quotes in stuff you thought was numeric. Regex to make
sure it's really numeric, plus range checking, should be enough.
How does PHP handle arithmetic operations on stuff like:

if ($month < 1 || $month > 12) { ...handle bad month error; }

where $month = "3'or 1";

Have you considered detecting when this happens, and logging relevant
things, like $_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_REFERER'],
and $_SERVER['HTTP_USER_AGENT'] ?

This was brought to my attention this morning. I added a dump of the
$_SERVER array to the email. When I have more than a couple to look at,
I'll try to find a thread.

Are you getting blank messages *IN SPITE OF* the check above, or
did you put the check in because you kept getting blank messages?
If you are still getting blanks in spite of the check, that's wierd.

The check has been in since the beginning. That's primarilly what I
don't understand. In the resulting email, a healthy message might read
"first_name: John". In the errant messages, the line reads
"first_name:". Not even a space. (adding values to the database uses

Ok, I thought you were getting *COMPLETELY BLANK* messages. You
seem to be getting field names. And I don't understand not getting
a space since your code had a colon followed by a space after the
key.
trim(), but generating the email uses the raw post values). In the
$key=>$val clause, it would seem that $key is filled with the names of
my input fields but $val is null. Would $_POST have an element for a
given input field if the field were null?

If the field is empty, you'd get an empty string (I forget whether
PHP makes a distinction between an empty string and null like SQL
does). I believe this is what you get when someone clicks on the
form without filling anything in (and JavaScript either doesn't
catch it or is turned off).

if ($_POST['first_name'] == '' && $_POST['last_name'] == '') {
... bad message, ignore it ...;
}

Gordon L. Burditt

Jul 17 '05 #7

dmcconkey

> seem to be getting field names. And I don't understand not getting

a space since your code had a colon followed by a space after the
key.

My error. The space after the colon _is_ in there. I meant that I'm not
getting an additional space, one that would represent someone just
putting a space in the field to bypass the JavaScript.

Jul 17 '05 #8

Alvaro G Vicario

*** dm*******@yahoo.com wrote/escribió (14 Jun 2005 12:43:39 -0700):

Does GoogleBot (or any other bot for that matter) identify itself
within the USER_AGENT string?

Search engine bots normally do so, esp. Google's.

--
-- Álvaro G. Vicario - Burgos, Spain
-- http://bits.demogracia.com - Mi sitio sobre programación web
-- Don't e-mail me your questions, post them to the group
--

Jul 17 '05 #9