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)?
22  1460 
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. js*******@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 <no*****@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 <no*****@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. js*******@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 helper
functions would really make sense here.
Micha
Rik Wasmus wrote:
>
On Sat, 26 Apr 2008 08:04:58 +0200, William Gill <no*****@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 help.
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 help.
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 help.
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. js*******@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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Raptor |
last post by:
I'm using a single script to generate a table with <input>s in each row.
I fill the array with initial values, then write it out to the table
and let the user edit the values. Something like:
...
|
by: AJ Z |
last post by:
I am using in_array() to search for a value ("other"), in order to validate
a form.
If I pass $_POST as the array to search PHP says that it is an
invalid datatype.
It is an array and if I copy...
|
by: Adrian Parker |
last post by:
Is it possible to click on a button, and not have it's value and name stored
in _POST?
I have this script with a button on it. When you click the button, the page
posts to itself. The first...
|
by: billy.becker |
last post by:
I need to save a wav file that is HTTP POSTed to a php page.
What does PHP5 do automatically to a POSTed variable when it puts it in
the $_POST superglobal array? I haven't been able to find any...
|
by: Dynamo |
last post by:
I am using values stored an $_POST array to display records from a table before
asking the user if he is sure he wants to delete them. If the user confirms then
the records are deleted. Without...
|
by: RDizzle |
last post by:
okay. so all i am doing is changing a registration script that uses
$_GET to a script that uses $_POST, but the validation script now
returns NULL values for all posted vars.
What's the deal?
...
|
by: comp.lang.php |
last post by:
I have no idea why this is happening and I need someone to explain this
to me at the simplest level absolutely possible (pretend I'm a 10-year
old and explain it that way, please!)
This class...
|
by: comp.lang.php |
last post by:
// NEW 11/27/2006: FINALLY, IF YOU ADDED OR DELETED OR DID ANY KIND OF
FORM ACTION SUCCESSFULLY, DON'T RE-DISPLAY THE NEW EXPENSE ITEMS VIA
$_POST
if ($_POST && (!is_array($leaseObj->errorArray)...
|
by: Tarantulus |
last post by:
Hi,
ok, quick description of the problem, I'm trying to reference the postdata from some checkboxes. Unfortunately the checkboxes are dynamically generated therefore I don't know how many there...
|
by: lawpoop |
last post by:
Hello all -
Is there a way to get a nested array in a $_POST variable?
I have a form where there are several questions, each one
corresponding to a database row. On submission of the form, I...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
