-- Ed Finkler <[EMAIL PROTECTED]> wrote (on Thursday, 22 March 2007, 01:27 PM -0400): > On 3/22/07, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote: > > Please remember that Zend_Controller_Request_* was built to help with > > routing and dispatching -- which is why getParam() pulls from a variety > > of sources (when determining how to route a request, the salient input > > could come from a variety of sources -- the path, query parameters, post > > parameters, etc.). It was never intended as a general-purpose object for > > input filtering -- that's a goal for a later iteration, which will still > > need to account for the variety of sources when dealing with routing. > > That security considerations are not part of the initial > implementation, but something added later in the process, is in and of > itself worrisome.
There's a heavy amount of filtering going on in the router and dispatcher -- that's where the security is residing for this implementation. Zend_Controller_Request_Abstract has *no* methods for interacting with the environment whatsoever -- simply accessors for setting parameters and module/controller/action values. The HTTP version is designed to pull information out of the HTTP environment in order to aid routing and dispatch tasks; this includes the path, query string parameters, post variables, cookies, and more. Again, the point was not for general purpose consumption by userland scripts. However, since it is made accessible by the action controllers (in order to allow things like action forwarding), many have used it for pulling data in much the way $_REQUEST has been used in the past. Once I realized people were using the request object in order to pull GET and POST data -- instead of accessing those superglobals themselves, or using a proxy such as Zend_Filter_Input, I realized that this would be a security vector. However, without stable validation/filtering classes ready, this simply could not be addressed properly. Now that they are, we can begin addressing this. This is why I mentioned that it will be dealt with in a later iteration. Any solution will need to remain backwards compatible with the current API, however. This should not be difficult due to the nature of the accessors. -- Matthew Weier O'Phinney PHP Developer | [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
