Well, my point was that because any of those can be manipulated (POST, GET, COOKIE, etc.), selecting from a specific source can lead to a false sense of added security. Better to make your application capable of reliably accepting data from any source and acting on it appropriately. In other words, to deal with user data as if it had come from a single source: the user.
-Matt On Thu, March 22, 2007 3:27 pm, Pádraic Brady wrote: > np ;), but isn't that the same or a related point I reiterated? Yes, > developers should be aware data can come from anywhere, which also makes > it important they know to narrow down access methods to eliminate > unexpected ones - standard security practice. Surely that was always the > problem of using $_REQUEST in preference to deliberately selecting one of > $_POST, $_GET, $_COOKIE. Just as improperly relying on getParam (since > it's currently an accessible public method) instead of getPost hides where > the data came from, adding an unnecessary element of risk which today we > see in CSRF vectors. All I intended to note (sorry if my wording was > obscure!) was using a multi-source method was bad practice. I have bad > habit I think of stating the obvious across a page of text :). Yep, > definitely bad. > > Also, I wish I understood or had read more about the Request object. It > was my impression the Request object was not solely intended for > controller logic. I guess I misinterpreted its uses since it seemed a > natural fit for any standard Request object - really should note the > distinction in the manual because it should be avoided if that's the case. > Or maybe I should read the manual more often in case it already is! > > Pádraic Brady > http://blog.astrumfutura.com > http://www.patternsforphp.com > > > ----- Original Message ---- > From: Matthew Ratzloff <[EMAIL PROTECTED]> > To: Zend Framework General <fw-general@lists.zend.com> > Sent: Thursday, March 22, 2007 6:23:47 PM > Subject: Re: [fw-general] Zend_Filter_Input... > > "[I]f we have too many sources for input variables, some of which check > varying sources in priority it's just another $_REQUEST situation where > these values could conceivably come from anywhere." > > The data DOES come from anywhere. Data is not somehow more secure if it > is POST. POST variables can be manipulated with only slightly more > difficulty in a browser than modifying the query string, and when using > something like cURL or Zend_Http_Client the difference is insignificant. > > Data should be checked not only for "well-formedness" (e.g., correct data > type) but also for validity and access rights. Whatever filtering > solution is created post-1.0, it is not going to be a comprehensive > solution unless used in combination with Zend_Validate, Zend_Auth, and > Zend_Acl. > > Most PHP developers either don't understand this, don't care about this, > or their development timeline is paced so ridiculously short that they > don't have time to deal with it. Most of the time it's one of the first > two. In the third case, I've had to show clients numerous times how easy > it is to get into supposedly secure web applications, just to show how > important it is to get it right. You would be surprised how little > difficulty you encounter when trying to gain access to supposedly secure > web systems because of attitudes like "it comes from POST, therefore it's > more secure". > > Not trying to pick on you, Simon and Pádraic. :-) But I would actually > PREFER that developers always be aware that their data can come from > anywhere, just so they stay paranoid. > > -Matt > > On Thu, March 22, 2007 3:36 am, Pádraic Brady wrote: >> In agree with you Simon - if we have too many sources for input >> variables, some of which check varying sources in priority it's just >> another $_REQUEST situation where these values could conceivably come >> from anywhere. It's better practice to use a method which selects >> values from a known source on the basis if it comes from anywhere else >> unexpectedly it should ring a few alarm bells for the developer. I'd >> actually call it first line filtering/validation - if we know a value >> should be received via POST then if the same value is retrievable from >> GET it should be ignored unless it's for a valid reason. >> Pádraic Brady >> http://blog.astrumfutura.com >> http://www.patternsforphp.com >> >> >> ----- Original Message ---- >> From: Simon R Jones <[EMAIL PROTECTED]> >> To: Zend Mailing List <fw-general@lists.zend.com> >> Sent: Thursday, March 22, 2007 8:13:19 AM >> Subject: RE: [fw-general] Zend_Filter_Input... >> >>> You can use $this->_getParam('key', 'default'); in a Controller, >>> because >>> _getParam() use the Request->getParam() method, which tries first to >>> load the param from the url, then from $_GET and after this from >>> $_POST. >> >> If $this->_getParam() looks at the URL, GET and POST isn't it a >> potential >> security issue to use it for POST variables since you don't know exactly >> where your input variables are coming from? >> >> Seems rather similar to $_REQUEST to me which should also be avoided for >> similar reasons - >> http://shiflett.org/articles/ideology >> >> A quick look at the (nicely growing) manual it seems you can do the >> following which does the job nicely for POST variables: >> >> $myVar = $this->getPost('name'); >> >> (See API docs / Zend_Controller_Request_Http for more) >> >> There do seem to be a lot of methods that return variables from GET, >> POST, >> COOKIE, etc. I think it would be a good idea to mention the security >> implications of depending on these in the manual.. >> >> Si > > > > > > > > > > ____________________________________________________________________________________ > Food fight? Enjoy some healthy debate > in the Yahoo! Answers Food & Drink Q&A. > http://answers.yahoo.com/dir/?link=list&sid=396545367
