On 03/14/2012 03:11 PM, Stas Malyshev wrote: > Hi! > >> The other way to solve this would be to make max_input_vars PHP_INI_ALL >> and then just let people ini_set() their way around the limit. > > I think making it PHP_INI_ALL is OK. If you have access to a way to > change INI_ALL vars, that means you can run code on that system, then > DoS protection is meaningless on this stage.
I ran into this in some existing code that broke upgrading to 5.3.10. It was a backend call to an API where the API result was being fed to parse_str(). The API itself is trusted, so no risk of a HashDoS from it. Other than replacing the call to parse_str() with a similar userspace implementation there was no way to fix this safely. I could do a .htaccess for just that URI, but that would open up the frontend of this particular request to a HashDoS. I'll make the INI_ALL change for the next release. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
