$_POST vs $_REQUEST
in [General]
|
From: "David Murphy" on 22 Feb 2010 16:30 Richard, The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, they should ALL be treats as bad data until normalized and sanitized. The claim that it opens a security hole is just false, thats like saying PHP is insecure, its not it just allows for lazy coding such as $_REQUEST. David Murphy -----Original Message----- From: richard.heyes(a)gmail.com [mailto:richard.heyes(a)gmail.com] On Behalf Of Richard Sent: Monday, February 22, 2010 3:03 PM To: Joseph Thayne Cc: Slack-Moehrle; php-general Subject: Re: [PHP] $_POST vs $_REQUEST Hi, > I am not sure what the security issues are you are referring to as the > $_REQUEST superglobal contains both $_GET and $_POST values. Could you > expound on that? Thanks. Not really, do a search. -- Richard Heyes HTML5 canvas graphing: RGraph - http://www.rgraph.net (updated 20th February) Lots of PHP and Javascript code - http://www.phpguru.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
From: Michael Shadle on 22 Feb 2010 16:37 On Mon, Feb 22, 2010 at 1:30 PM, David Murphy <david(a)icewatermedia.com> wrote: > Richard, > > > The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, > they should ALL be treats as bad data until normalized and sanitized.  The > claim that it opens a security hole  is  just false, thatâs like saying PHP > is insecure, its not it just allows for lazy coding such as $_REQUEST. It represents a way for people to exploit coders who don't know any better. Expecting a cookie value to come through in $_REQUEST but you could override using a query string parameter makes for easy exploitation. Probably not catastrophic but much easier to brute force things if you don't have to bother with cookies, or can fake a user identity easier; things of that nature. If you coded your app well, in theory it won't make much difference, however, why keep something out there that makes it easier for people to mess with your site, period?
From: Slack-Moehrle on 22 Feb 2010 17:02 John, >>Then if you use a MySQL database you would escape the string like this >>$tmp = mysql_real_escape_string($_REQUEST['yyy']); >>mysql_real_escape_string() protect from SQL injection by escaping your >>string according to what your charset requires. Good point, I should be doing that. But only to String, not data stored in MySQL as Int or Date, etc. -ML
From: John Black on 22 Feb 2010 17:07 On 02/22/2010 10:37 PM, Michael Shadle wrote: > On Mon, Feb 22, 2010 at 1:30 PM, David Murphy<david(a)icewatermedia.com> wrote: >> Richard, >> The use of $_REQUEST it no more a security hole than $_GET or $_REQUEST, >> they should ALL be treats as bad data until normalized and sanitized. The >> claim that it opens a security hole is just false, that's like saying PHP >> is insecure, its not it just allows for lazy coding such as $_REQUEST. > It represents a way for people to exploit coders who don't know any better. > Expecting a cookie value to come through in $_REQUEST but you could > override using a query string parameter makes for easy exploitation. And how is this more secure? I can create a cookie, send post or get on my client machine and send anything I want to the server. Just because you are getting a cookie does not mean that you created it :) So you might as well use request because the data can not be trusted either way. -- John Gerechtigkeit entspringt dem Neid; denn ihr oberster Grundsatz ist: Allen das Gleiche. [Walther Rathenau]
From: Michael Shadle on 22 Feb 2010 17:17
On Mon, Feb 22, 2010 at 2:07 PM, John Black <spam(a)network-technologies.org> wrote: > And how is this more secure? I can create a cookie, send post or get on my > client machine and send anything I want to the server. Just because you are > getting a cookie does not mean that you created it :) > > So you might as well use request because the data can not be trusted either > way. Kind of like saying "why bother exercising and keeping healthy - we're going to die anyway" "Secure" might be the wrong term here. As you can easily change GET to POST and vice-versa and send any cookies you like, this is why I tried to revise my statement and quantify it better... in a properly coded app it doesn't present much issue. However, it encourages laziness and PHP's barrier to entry is so easy that there is a lot of people who consider a cookie to be trusted, and overriding it with a simple GET parameter is too easy of an attack vector. At least make it difficult. |