I hate to ressurect old threads, but i saw this little advisory come by on tonight and it seemed on topic. it had to do with a SQL injection vulnerability on phpmyadmin that has to do with the authors of the software using $_REQUEST instead of $_GET and $_POST. it states:
"An attacker could entice a user to visit a malicious web application that sets an "sql_query" cookie and is hosted on the same domain as phpMyAdmin, and thereby conduct SQL injection attacks with the privileges of the user authenticating in phpMyAdmin afterwards." http://www.gentoo.org/security/en/glsa/glsa-200803-15.xml So yes in some situations you can get your cookies stolen using $_REQUEST improperly. hope this sheds some light Regards On 2/29/08, Mac Newbold <[EMAIL PROTECTED]> wrote: > > > 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 > _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
