I am working on some things to harden PHP against filter chain attacks:
• PHP RFC: Limit maximum number of filter chains https://wiki.php.net/rfc/limit-maximum-number-of-filter-chains
• Dechunk incorrectly truncates string when it starts with a hex character https://github.com/php/php-src/issues/21983
The idea of the RFC is great to me! Now, I have some thoughts concerning the dechunk filter.
There have been a idea to deprecate this filter [1], and I think it makes sense. The dechunk filter is often used in exploits (as you've said in your RFC, to be short it behaves different according to the first char of a stream so it is widely abused in blind injections), and is not documented. That is, most php devs likely do not even aware of this filter, except for malicious attackers.
Now, as the PR comment [2] said, "The dechunk filter is used by http stream wrapper when Transfer-Encoding: chunked is used so it cannot be completely deprecated." That's true, but opening this filter through php://filter makes little sense to me. I think if the goal of your RFC is to harden security of php filters, then maybe we could directly deprecate the dechunk filter in 8.6. I don't think there will be too much BC break because it is not documented anyways, so people shouldn't (or is not recommended) to use this in the first place. wdyt?
(This is not associated with your RFC of limiting the maximum length, I am just speaking under your topic of "Hardening PHP against filter chain attacks" since you are working on it.)
Thanks, Weilin Du
[1]: https://github.com/php/php-src/issues/22036#issuecomment-4443988412_
[2]: https://github.com/php/php-src/issues/22036#issuecomment-4448769434_