$_POST vs $_REQUEST
in [General]
|
From: Andrew Ballard on 22 Feb 2010 17:21 On Mon, Feb 22, 2010 at 5:02 PM, Slack-Moehrle <mailinglists(a)mailnewsrss.com> wrote: > 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 Just to clarify, while you would not use mysql_real_escape_string() for datatypes other than strings, you still need to do filtering, validation, and sanity checking on other datatypes as well. As I pointed out in another thread recently, these are just as vulnerable to SQL injection even though the variable values are expected to be integers or dates: $sql = "SELECT `my_id`, `my_message` FROM `my_comments` WHERE `my_id` = $my_id"; $sql = "SELECT `post_id`, `post_text`, `post_date` FROM `blog_posts` WHERE `post_date` BETWEEN '$first_post_date' AND '$last_post_date'"; IMO mysql_real_escape_string() (or any similar function used for different db vendors) is just a method to escape sequences that have special meaning in a SQL query. It is the LAST step you should perform when processing input to be saved in a MySQL database (when parameterized queries are not available), after you have done everything you can to ensure that ALL the values being passed in the query are valid. Andrew
From: John Black on 22 Feb 2010 17:26 On 02/22/2010 11:17 PM, Michael Shadle wrote: > "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. Just because someone believes that a cookie is something that can be trusted does not make it so. A properly coded app should not care how the client sends the information, only that the information is it valid and expected. A cookie is the same thing as $_POST or $_GET data but it can be stored for a period of time, what happens to the stored data is out of our control. Treating one any different from the other is just wrong and will create apps with security holes. For anybody who would like to try the GUI version of tampering with data sent to the server checkout TamperData for FireFox. -- John Klarmachen zum Ändern! http://www.youtube.com/v/AYM-_qfytfA
From: Daniel Egeberg on 22 Feb 2010 17:35 On Mon, Feb 22, 2010 at 22:37, Michael Shadle <mike503(a)gmail.com> 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. > 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? Using $_REQUEST poses no security issues whatsoever. Just because there are incompetent programmers doesn't mean that a language feature is inherently insecure. It's entirely dependent on how you use it. A pen is also dangerous if you stab someone in the eye with it. Certain features in PHP may be dangerous if you give them to incompetent people who don't know what they're doing. Besides, whether or not you can "override" cookie values depends on whether the programmer also uses $_REQUEST for cookie values and the request_order php.ini directive. The value in the php.ini files that ship with PHP 5.3 default to only including GET and POST data for instance: http://svn.php.net/viewvc/php/php-src/tags/php_5_3_1/php.ini-production?view=markup#l671 If an attacker can do an HTTP GET request, he can most likely also do an HTTP POST request (and vice versa) and the input value will be no more (in)secure regardless of the source. Using $_GET/$_POST in place of $_REQUEST is no more than security theater in my opinion. -- Daniel Egeberg
From: Michael Shadle on 22 Feb 2010 17:42 The difference here is you can at least have some control over the data and expect it in a certain fashion. Also the behavior of cookies vs. get vs. post are different (cookies have length and expiration limits, get has length limits, post has server confgured limits) Like I said a properly coded app won't really suffer much but why allow for lazy coding practices and non properly coded apps to be exploited as easy? The great deal of apps out there are not properly coded. Again I reference my metaphor about dying. At least try to put effort into something. On Feb 22, 2010, at 2:26 PM, John Black <spam(a)network- technologies.org> wrote: > On 02/22/2010 11:17 PM, Michael Shadle wrote: >> "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. > > Just because someone believes that a cookie is something that can be > trusted does not make it so. A properly coded app should not care > how the client sends the information, only that the information is > it valid and expected. > > A cookie is the same thing as $_POST or $_GET data but it can be > stored for a period of time, what happens to the stored data is out > of our control. Treating one any different from the other is just > wrong and will create apps with security holes. > > For anybody who would like to try the GUI version of tampering with > data sent to the server checkout TamperData for FireFox. > > -- > John > Klarmachen zum Ãndern! > http://www.youtube.com/v/AYM-_qfytfA > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >
From: Jochem Maas on 22 Feb 2010 17:46
Op 2/22/10 8:39 PM, Slack-Moehrle schreef: > Hi All, > > I have Forms that I submit for processing. I have seen examples of people using either $_POST or $_REQUEST. > > When would I choose one over the other? use $_POST, $_REQUEST is normally an amalgam of GET, POST and COOKIE - as such using $_REQUEST can open you up to a denial of service attack (if someone manages to place cookies with the same names as your form fields they will always override what was in the POST). avoid using $_REQUEST. > Also, I see examples of these being used with and without the single quotes > > Like: > > $_POST[j_orderValue] this generates an E_NOTICE and is bad practice, it's also slower, essentially PHP sees the CONSTANT j_orderValue which it can't find and does it's best to accomodate sloppy code by tranlating it into the string 'j_orderValue' try turning up the ini setting 'error_reporting' to include E_NOTICE warnings (and everything else) and see what else your code might be doing which isn't quite right ... it can be very helpful, I'm assuming you're running a local webserver, as running that in production is a bit pointless in my view (additionally having the ini setting 'display_errors' turned on in production is a security issue) > or > $_POST['j_orderValue'] > > Single quotes is best, correct to prevent sql injection? this does nothing for SQL injection prevention, for that you need the escaping function for the DB you use ... for MySQL that would be mysql_real_escape_string(). > -ML > |