[UPHPU] receiving with $_REQUEST

Mac Newbold mac at macnewbold.com
Fri Feb 29 09:12:31 MST 2008

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 

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


> 3) good programming should be secure.  Absolutely no argument there.
> Additionally, it should be scaleable, flexible, and accessible.


> 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
> 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 Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/

More information about the UPHPU mailing list