From: John Black on 22 Feb 2010 17:49 On 02/22/2010 11:42 PM, Michael Shadle wrote: > 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) The cookie and post/get part is all mixed up now :) I use $_COOKIE when I want cookie information but I know that the data is not to be trusted and is easily fabricated. When reading get or post I just use $_REQUEST nowadays because I don't have to care how the submitting form is written. This makes my form handling data more portable. -- John You may say I'm a dreamer, but I'm not the only one, I hope some day you'll join us, And the world will live as one. [John Lennon]
From: Ashley Sheridan on 22 Feb 2010 18:44 On Mon, 2010-02-22 at 23:49 +0100, John Black wrote: > On 02/22/2010 11:42 PM, Michael Shadle wrote: > > 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) > > The cookie and post/get part is all mixed up now :) > > I use $_COOKIE when I want cookie information but I know that the data > is not to be trusted and is easily fabricated. > > When reading get or post I just use $_REQUEST nowadays because I don't > have to care how the submitting form is written. This makes my form > handling data more portable. > > -- > John > You may say I'm a dreamer, but I'm not the only one, > I hope some day you'll join us, And the world will live as one. > [John Lennon] > As many people have mentioned already, there's absolutely no security risk of using $_REQUEST over $_POST or $_GET. I generally use $_REQUEST unless I am specifically coding something that needs me to send data over both post and get at the same time. The thing is, just make sure you sanitise all the data that comes from the browser. That includes cookie values, post data, etc. Proper sanitisation is crucial and necessary, and no amount of obscurity about how you are getting your data will help. Thanks, Ash http://www.ashleysheridan.co.uk
From: Richard on 23 Feb 2010 04:19 Hi, Well people better than me (how is that possible?!) have said that $_REQUEST has the potential to open your app up to security vulnerabilities, and that it should be avoided because of that. Here's a post from Stephan Esser about it on the PHP-Internals list: http://www.mail-archive.com/internals(a)lists.php.net/msg32832.html Stephan heads up the Hardened-PHP project and when it comes to security, I don't know of anyone better. So, if he advises not to use _REQUEST, it's a good idea to follow that advice. -- Richard Heyes
From: Ashley Sheridan on 23 Feb 2010 05:27 On Tue, 2010-02-23 at 09:19 +0000, Richard wrote: > Hi, > > Well people better than me (how is that possible?!) have said that > $_REQUEST has the potential to open your app up to security > vulnerabilities, and that it should be avoided because of that. Here's > a post from Stephan Esser about it on the PHP-Internals list: > > http://www.mail-archive.com/internals(a)lists.php.net/msg32832.html > > Stephan heads up the Hardened-PHP project and when it comes to > security, I don't know of anyone better. So, if he advises not to use > _REQUEST, it's a good idea to follow that advice. > > -- > Richard Heyes > Well, he's only saying there that it 'most probably vulnerable' and mentions that cookies can overwrite post and get data. This isn't a problem with $_REQUEST itself but rather an applications' use of it. So what if someone crafts a cookie to send a bad value. If someone has the gen to do that, then they are going to know how to send get and post values as well. Only decent sanitisation will be able to protect against this. If the order of override variables in $_REQUEST is such an issue too, use the request_order ini setting to specify the order you'd prefer. I've never had any issues with using $_REQUEST, but found a lot of advantages to using it, as I often use a mix of data sources in the same app. Thanks, Ash http://www.ashleysheridan.co.uk
From: "Bob McConnell" on 23 Feb 2010 08:42
From: Rene Veerman [mailto:rene7705(a)gmail.com] > On Mon, Feb 22, 2010 at 9:39 PM, Slack-Moehrle >> >> Single quotes is best, correct to prevent sql injection? > > sql injection fixing is an evolving art, but you can start by pushing > all variables that can be changed by end-users going into a database > through a marshalling-function fixSQLinjectionToDB ($var) { return > addslashes($var); }; > addslashes is the minimum fix i believe, but google around and give us > back the up-to-date uber-fix-function please :) Slash is the wrong character. The correct SQL escape character is the single quote. The best way to prepare text fields is to use the DB specific escape functions on each text field before assembling the command string, i.e. pg_escape_string(). But that is after all fields have been sanitized and validated. In addition, if magic_quotes is turned on, you also need to remove them before doing the validation. The contributed notes in the online manual have some good suggestions on how to accomplish this. Bob McConnell |