On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
>> The more stuff like this we remove, the harder it becomes for people to >> quickly move to newer, faster and more secure versions of PHP. That >> causes way more frustration for everyone than a few "ugly" legacy >> features. If there is a decent technical reason, performance or >> security, then we need to take a hard look at it. In this case, the >> thing we should be looking at isn't whether we should remove $_REQUEST >> but whether we should remove cookie data from it. Many configurations >> already do that, including all of my own, and there is a strong valid >> security reason for not including cookies in $_REQUEST. Most people use >> $_REQUEST to mean GET or POST, not realizing that it could also contain >> cookies and as such bad guys could potentially do some cookie injection >> tricks and break naive applications. But since there is going to be a dramatic change here anyway, this is the perfect time to do it. To me adding namespaces is a lot more scary and will lead to a lot of confusing code... P.S. It looks like you'll be speaking at OSBridge in Portland in a month or so. If I attend I look forward to meeting you and thanking you for PHP :) > Its already fixed in 5.3. There is a new ini option that defines what should > go into $_REQUEST. See the following blog post for details: > http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ > > Also a lot of work was put into restructuring the php.ini files we ship with > PHP. This is a good step I think; will it be possible to allow it to be empty and have $_REQUEST not exist or even be initialized? Also, you said it yourself in your blog - not caring what is done via GET and POST is bad practice. Why not enforce this in the engine? It makes PHP look insecure when apps have security issues because of poor coding. It's not because PHP itself had a flaw, but to a lot of people, they see "PHPNuke" or know that postnuke runs under PHP, or phpbb, etc - the language -can- enforce better techniques, especially since 5.3 and 6.0 will require some changes in code anyway; this one is a pretty simple change too - Someone could make a function like import_request_variables() but allow it to re-create $_REQUEST and tell people to put it at the top of their scripts or a central include file if they're too lazy to fix their code to be more secure. I for one would love to see this be enforced at the engine level, so that packages I wind up having to use like Wordpress/etc. have been forced to change their logic (hopefully) to go back to $_GET, $_POST etc. Also, I had thought $_REQUEST had included session data too. At least that is not there. Talk about easy exploitation options then! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
