This may sound stupid but, in my testing I have noticed that I get every
form field ($_POST array key), even if not populated. I am sure that's
not how things worked before, but the point is, is it now safe to
address $_POST array keys without testing to see if they exist (as long
as I know the form field name exists)?

William Gill wrote:
> This may sound stupid but, in my testing I have noticed that I get every
> form field ($_POST array key), even if not populated. I am sure that's
> not how things worked before, but the point is, is it now safe to
> address $_POST array keys without testing to see if they exist (as long
> as I know the form field name exists)?
>
>

No, it's never safe to trust user input. For instance, they may have
just issued a GET request for the form processing page. Or they could
have created their own form, pointing at your processing page, with
their own stuff in it (i.e. hackers).

And unchecked checkboxes do not get sent.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

*** William Gill escribió/wrote (Fri, 25 Apr 2008 16:54:36 -0400):
> This may sound stupid but, in my testing I have noticed that I get every
> form field ($_POST array key), even if not populated. I am sure that's
> not how things worked before

More or less, that's how it's always worked. Browsers sends all form fields
except:

- Fields with "disabled" attribute
- Unchecked checkboxes

> but the point is, is it now safe to
> address $_POST array keys without testing to see if they exist (as long
> as I know the form field name exists)?

For God's sake, *never* trust external data!


--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor en cubitos: http://www.demogracia.com
--

On Fri, 25 Apr 2008 22:54:36 +0200, William Gill <noreply@example.com>
wrote:

> This may sound stupid but, in my testing I have noticed that I get every
> form field ($_POST array key), even if not populated. I am sure that's
> not how things worked before, but the point is, is it now safe to
> address $_POST array keys without testing to see if they exist (as long
> as I know the form field name exists)?

I suspect the only thing that would cause this to your perception is a
different error_reporting level where notices aren't called to your
attention anymore.

Keep testing for existance of POST keys before doing anything elese.
--
Rik Wasmus

Jerry Stuckle wrote:

> No, it's never safe to trust user input.
I don't. But I could swear that empty fields didn't have corresponding
$_POST keys before. Now I get every field/key, so I was thinking I
didn't have to perform an array_key_exists( 'fieldname', $_POST ).

>
> And unchecked checkboxes do not get sent.
>

I didn't have any checkboxes on the form I was testing, I'll test
against them.

Álvaro G. Vicario wrote:
> More or less, that's how it's always worked. Browsers sends all form fields
> except:
>
> - Fields with "disabled" attribute
> - Unchecked checkboxes

I could have sworn I didn't get empty fields before.

> For God's sake, *never* trust external data!
I don't. I didn't want to perform an array_key_exists( 'fieldname',
$_POST ) before I test what value they contain.

..oO(William Gill)

>Jerry Stuckle wrote:
>
>> No, it's never safe to trust user input.
>I don't. But I could swear that empty fields didn't have corresponding
>$_POST keys before. Now I get every field/key

Empty form fields are always submitted, because they actually have a
value - an emtpy string. That's different from having no value at all.

>so I was thinking I
>didn't have to perform an array_key_exists( 'fieldname', $_POST ).

Such checks (usually with isset()) should always be done.

Micha

Rik Wasmus wrote:
> I suspect the only thing that would cause this to your perception is a
> different error_reporting level where notices aren't called to your
> attention anymore.
>
> Keep testing for existance of POST keys before doing anything elese.

foreach($_POST as $key => $val){} returns all keys, even for empty
fields. I don't remember things working that way before. However, I'm
not sure about the errors. I'll have to do some more testing.

On Sat, 26 Apr 2008 08:04:58 +0200, William Gill <noreply@example.com>
wrote:

> Rik Wasmus wrote:
>> I suspect the only thing that would cause this to your perception is a
>> different error_reporting level where notices aren't called to your
>> attention anymore.
>> Keep testing for existance of POST keys before doing anything elese.
>
> foreach($_POST as $key => $val){} returns all keys, even for empty
> fields. I don't remember things working that way before. However, I'm
> not sure about the errors. I'll have to do some more testing.

Oh yes, that always worked like that to my knowledge (save for
checkboxes). An empty string is still a value, and perhaps even an
important one.
--
Rik Wasmus

Michael Fesser wrote:
> Empty form fields are always submitted, because they actually have a
> value - an emtpy string. That's different from having no value at all.

I don't remember it working that way in practice, but I may be confusing
PHP and other script engines (like Python). I guess it doesn't matter
what I remember or not.

> Such checks (usually with isset()) should always be done.
Probably right. For some reason I was getting the impression I could
skip that in lieu of other things, but..

I was adding the following to input fields...

class="<?php echo array_key_exists('First_Name', $form_errors) ? 'error'
: 'normal'?>" value="<?php echo array_key_exists('First_Name', $_POST)?
htmlentities( $_POST['First_Name'],ENT_QUOTES) : '' ?>"

.... and now I may have to retool my thinking a little. Might be cleaner
to create a function instead.

William Gill wrote:
> Álvaro G. Vicario wrote:
>> More or less, that's how it's always worked. Browsers sends all form
>> fields
>> except:
>>
>> - Fields with "disabled" attribute
>> - Unchecked checkboxes
>
> I could have sworn I didn't get empty fields before.
>
>> For God's sake, *never* trust external data!
> I don't. I didn't want to perform an array_key_exists( 'fieldname',
> $_POST ) before I test what value they contain.
>
>

Use isset($_POST['fieldname']).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(William Gill)

>Michael Fesser wrote:
>> Empty form fields are always submitted, because they actually have a
>> value - an emtpy string. That's different from having no value at all.
>
>I don't remember it working that way in practice

You've already said that ;-), but it always worked that way as far as I
can remember.

>but I may be confusing
>PHP and other script engines (like Python).

Quite possible.

>I guess it doesn't matter
>what I remember or not.
>
>> Such checks (usually with isset()) should always be done.
>Probably right. For some reason I was getting the impression I could
>skip that in lieu of other things, but..
>
>I was adding the following to input fields...
>
>class="<?php echo array_key_exists('First_Name', $form_errors) ? 'error'
>: 'normal'?>" value="<?php echo array_key_exists('First_Name', $_POST)?
> htmlentities( $_POST['First_Name'],ENT_QUOTES) : '' ?>"
>
>... and now I may have to retool my thinking a little. Might be cleaner
>to create a function instead.

Indeed. Such things are done over and over again, so some little er
functions would really make sense here.

Micha

Rik Wasmus wrote:
>
> On Sat, 26 Apr 2008 08:04:58 +0200, William Gill <noreply@example.com>
> wrote:
>
<snip>
>> ... I don't remember things working that way before. However,
>> I'm not sure about the errors. I'll have to do some more testing.
>
> Oh yes, that always worked like that to my knowledge (save for
> checkboxes). An empty string is still a value, and perhaps even an
> important one.

I guess that's why old people (like me) shouldn't be doing this.

Jerry Stuckle wrote:
> William Gill wrote:
<snip>
>> I don't. I didn't want to perform an array_key_exists( 'fieldname',
>> $_POST ) before I test what value they contain.
>>
>>
>
> Use isset($_POST['fieldname']).
>
That's what I meant, array_key_exists wouldn't .

William Gill wrote:
> Jerry Stuckle wrote:
>> William Gill wrote:
> <snip>
>>> I don't. I didn't want to perform an array_key_exists( 'fieldname',
>>> $_POST ) before I test what value they contain.
>>>
>>>
>>
>> Use isset($_POST['fieldname']).
>>
> That's what I meant, array_key_exists wouldn't .

isset() seems to be a waste of time also, since every field is being set
even if only with an empty string.

William Gill wrote:
> William Gill wrote:
>> Jerry Stuckle wrote:
>>> William Gill wrote:
>> <snip>
>>>> I don't. I didn't want to perform an array_key_exists( 'fieldname',
>>>> $_POST ) before I test what value they contain.
>>>>
>>>>
>>>
>>> Use isset($_POST['fieldname']).
>>>
>> That's what I meant, array_key_exists wouldn't .
>
> isset() seems to be a waste of time also, since every field is being set
> even if only with an empty string.
>

But every field does NOT necessarily need to be set. For instance, a
hacker could create a page which links to yours and doesn't have those
fields set.

NEVER, NEVER, NEVER trust user input!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
>
> But every field does NOT necessarily need to be set. For instance, a
> hacker could create a page which links to yours and doesn't have those
> fields set.
>
> NEVER, NEVER, NEVER trust user input!
>

I use a session variable to reject input from any other page.
if ($_SESSION['secret'] != $_POST['secret'])

Besides, I fail to see where an unset field poses a threat. One set
with an unsafe value does, which is why I filter/validate IT not the key.

Am I missing something here?

William Gill a écrit :
> I use a session variable to reject input from any other page.
> if ($_SESSION['secret'] != $_POST['secret'])
And what prevents the hacker from looking at your HTML output to read
the "secret" variable, then parse through your site to generate the
session (without validating the site's form), and finally validate his
own HTML form on his local computer (which "action" would be the same as
the site's one) with the opened session he has with your server ?

> Besides, I fail to see where an unset field poses a threat. One set
> with an unsafe value does, which is why I filter/validate IT not the key.
Simple example: an empty password is a threat.
Maybe not your case, but it's a trivial example coming to my mind,
meaning there could be many more example, not as trivial, but that would
create (huge or not) security holes.

Regards,
--
Guillaume

Guillaume a écrit :
> William Gill a écrit :
>> Besides, I fail to see where an unset field poses a threat. One set
>> with an unsafe value does, which is why I filter/validate IT not the key.
> Simple example: an empty password is a threat.
> Maybe not your case, but it's a trivial example coming to my mind,
> meaning there could be many more example, not as trivial, but that would
> create (huge or not) security holes.

I should precise: unset field means $_POST['field'] would be empty and
generate an empty string.
Thus unset field may lead to unset value which was my point.

While your check script may check for the value "if set", and never deal
with the non-submitted values that still may be parsed through your code.
Well I admit it would be quite uncommon, but hackers love uncommon bugs :p

--
Guillaume

Guillaume wrote:
> William Gill a écrit :
>> I use a session variable to reject input from any other page.
>> if ($_SESSION['secret'] != $_POST['secret'])
> And what prevents the hacker from looking at your HTML output to read
> the "secret" variable, then parse through your site to generate the
> session (without validating the site's form), and finally validate his
> own HTML form on his local computer (which "action" would be the same as
> the site's one) with the opened session he has with your server ?
$secret is not a static value it's generated using a random number
algorithm when the session starts, and expires when the session expires.


>> Besides, I fail to see where an unset field poses a threat. One set
>> with an unsafe value does, which is why I filter/validate IT not the key.
> Simple example: an empty password is a threat.
> Maybe not your case, but it's a trivial example coming to my mind,
> meaning there could be many more example, not as trivial, but that would
> create (huge or not) security holes.
I validate every field's submitted value, even if a hacker got one in,
it wouldn't meet muster. The original question related to checking to
see if the field was set, which apparently it always is, even when empty.

I'm not trying to be argumentative, I am really trying to be sure what
I'm doing is what I think.

Guillaume wrote:
> I should precise: unset field means $_POST['field'] would be empty and
> generate an empty string.
> Thus unset field may lead to unset value which was my point.
>
> While your check script may check for the value "if set", and never deal
> with the non-submitted values that still may be parsed through your code.
> Well I admit it would be quite uncommon, but hackers love uncommon bugs :p
If my code doesn't do anything with unexpected fields, or empty strings,
or treats them as invalid entries, what is the threat?

William Gill a écrit :
> Guillaume wrote:
>> William Gill a écrit :
>>> I use a session variable to reject input from any other page.
>>> if ($_SESSION['secret'] != $_POST['secret'])
>> And what prevents the hacker from looking at your HTML output to read
>> the "secret" variable, then parse through your site to generate the
>> session (without validating the site's form), and finally validate his
>> own HTML form on his local computer (which "action" would be the same
>> as the site's one) with the opened session he has with your server ?
> $secret is not a static value it's generated using a random number
> algorithm when the session starts, and expires when the session expires.

Yep but to "POST" this value (since you get back a $_POST variable), it
must be included in the form, thus visible through the HTML source code.
Anybody can check your *HTML* source and get back that hidden field to
recreate it.

Then, anybody can create a .html file on his/her computer, recreate the
form with the required field, include the hidden input with the secret
value seen in the source, and post it as is, using for example a second
tab in firefox (having *your* form opened in the first tab means you
created the session, validating anything on the same server on a second
tab use the same session - this is not the case if you open a second
browser which would be a second process).

I did it not so far ago, when registering to a website where the
username on the forum could be specified but had to have at least 6
chars. I wanted to use 4, and the site was checking the length with a
(stupid) JavaScript. I recreated the form, removing the JS check, and
submitted it. Worked like a charm (and the admins never noticed the
length - or should I say they didn't care, since they knew me).

To secure that, you *could* check for the HTTP_REFERER being only your
server, but it also can be faked...

IMO, you can't reject input from any other page, you can just parse the
input and validate them all.

--
Guillaume

Guillaume wrote:
>
> To secure that, you *could* check for the HTTP_REFERER being only your
> server, but it also can be faked...
I was under the impression HTTP_REFERER was less reliable. I read
somewhere some browsers don't set it.

> IMO, you can't reject input from any other page, you can just parse the
> input and validate them all.
>
Which is what I do. I got in the habit years ago of checking to see if
the field was set first, but PHP always sets it, so why bother.