"[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 <[email protected]> > 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
