Re: Hardening PHP against filter chain attacks

> Your RFC says that most actual use is 1 or 2, with exploits > requiring 100+. Setting the default limit to say 16 should allow for > wacky use, but not the exploity variant. > > I would also likely find it better if there was no INI setting. If > you *really* must use more than 16, then you can always recompile > PHP. Some types of exploits using filters chain need way less than 100: - https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle - https://github.com/DownUnderCTF/Challenges_2022_Public/blob/main/web/minimal-php/solve/solution.py - https://github.com/ambionics/cnext-exploits/ Even https://github.com/synacktiv/php_filter_chain_generator, so generate the string <?php phpinfo(); ?> is about 100, and could likely be golfed to be below this threshold. And even those using 100+ chained filters can likely use multiple smaller chains instead. Limiting to 100 will block the low-hanging fruits, but it unlikely to solve the issue once and for all. Making it a configurable ini setting (with a sane default of 5?) would provide admins a way to tailor it to their application. I fail to come up with a legitimate usecase that would use more than 2 filters in the first place to be honest. >> What should the INI name be? filter.max_chain_depth > > I prefer no new INI setting, but perhaps 'filter.max_chain_length'. > It's not so much a depth, but a length. +1 for filter.max_chain_length