Awesome thread! It's been a while since we've gotten over 40 responses on
a topic like this. UPHPU Rocks! My thoughts are below.
Yesterday at 11:05pm, Chad Sollis said:
I was very excited about this thread (thanks wade), in hopes to curb a long
standing question I've had on this topic.
Although I appreciate and agree with most of what has been said, I still
have not heard anything convincing as to why not to use $_REQUEST. That
said, let me preface my comments with, I have no objection to using strict
definitions of $_POST or $_GET... But there is more to consider.
I agree - $_REQUEST is just a (useful) grouping of $_GET, $_POST, and
$_COOKIE in one variable. I _have_ most certainly found cases where it is
very helpful (both to the programmer and to the user) to be able to accept
_certain_fields_ from GET/POST/COOKIE without regard to which one it came
from.
My security thought for the day: GET, POST, and COOKIE (and $_FILES) are
all coming directly from the user. None of them can be trusted to be
anything other than data a user submitted, and all of them can be "forged"
or coerced to be any number of things your application might not have
expected. So, other than the lower barrier of entry argument, there's no
real security difference to me. How big the barrier of entry argument is
in terms of practical security concerns is debatable, but I would argue
that it is irrelevant. If the only thing protecting your app from security
breaches is a higher barrier, you've got problems. To be secure, you need
to be checking that everything is what you expected it to be, regardless
of whether it came from GET, POST, COOKIE, FILES, or REQUEST.
A few clarifying points:
1) all input regardless of how you obtain it needs to be "handled" or
cleansed properly before use. When RETRIEVING data, and using one variable
(like REQUEST) it is far more effecitve to treat all of this data in one
place.
Exactly! There are times where it matters where it came from, and times
where it is nice to be able to send a variable either way. I completely
agree about not sending sensitive data in a GET, nor about sending
non-idempotent operations via GET. (Anything that if done more than once
would cause a problem should always be a POST as you design your
application, but at the same time, there's not much harm in accepting GET
too, if someone were say using curl or wget to simulate the form post.
That said, you probably should be responsible and not accept anything
sensitive (credit cards) over GET (even though they're SSL encrypted)
because of the logging and such. It won't stop them from sending it, but
if it doesn't work, it will discourage it.)
2) people that use REQUEST are neither lazy or "dumb" or bad programmers, if
they use the variable appropriately
Amen!
3) good programming should be secure. Absolutely no argument there.
Additionally, it should be scaleable, flexible, and accessible.
Hallelujah!
4) using REQUEST isn't using HTTP protocols inappropriately. Its a
variable... Nothing more. If properly used, you are leveraging the actual
protocols. And can actually be quite powerful and effective.
You're on a roll!
The only REAL negative explanation from today's thread of using REQUEST is
the possibility of reading a cookie when you meant to read a GET/POST (this
of course could easily be managed in your handling/cleansing of the data. OR
in an environment where php.ini changes are accessible via .htaccess or
ini_set, the variable_order or gpc_order (both have PHP_INI_ALL access) can
be set to make cookies first read, and allow GET/POST to trump the cookie)
This is true, and as you said, easily dealt with. If you want to make sure
it wasn't the cookie you saw, you can check that $_COOKIE[$keyname] isn't
set to know that it was GET/POST, or simply check $_GET and $_POST instead
of $_REQUEST for that value.
A good programmer should assess the problem/application and weigh the pros
and cons of multiple scenarios and implications/accessibility of each. With
only 1 maybe 2, cons for using REQUEST, and a slew of positives, it COULD be
right for many applications. The common consensus in this thread is that
REQUEST poses no REAL DIFFERENT security threat, and the other concern is
easily managed, so please help me see the negative use here, seriously.
For anyone (and I assume many of you qualify here) that have used web
services extensively or APIs, either as a consumer or provider, knows that
both protocols are used frequently. In using Salesforce.com, ebay, amazon,
and several other webservices it is basically a necessity to accept/SEND
with either GET or POST. This could be accomplished with a bit of logic and
additional code around a strict definition of GET/POST or you could use
REQUEST.
Like I said, I am not saying that using GET/POST is wrong, but I am saying
that using REQUEST is very effective in many, many circumstances.
Agreed! Well said, Chad.
Many thanks for all your insight on this topic!
~Chad
Ditto! This has been a very fun thread to read.
And dataw0lf, we all know you're a real boy, no matter what names they
call you ;)
Mac
--
Mac Newbold MNE - Mac Newbold Enterprises, LLC
[EMAIL PROTECTED] http://www.macnewbold.com/
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
