Hi
On 2026-10-27 14:54, Máté Kocsis wrote:
1. I don't think `QueryParamParsingOptions::$maxQueryStringLength` is
necessary or useful to have. Checking the input length is easy to do
manually (it's just a `strlen()` call) and I don't see a practical
way
to abuse the API with large input lengths alone: The API will not
“blow
up” inputs into considerably larger data structures, the input
strings
are mostly just “copied” over, not too different from e.g.
`str_replace()`.
I was also thinking a lot about whether this option is necessary to
have.
My main reason for including it was that people would otherwise easily
forget
to limit the input length, whereas the dedicated option enforces the
limit
everywhere.
So the real question is whether QueryParams really cannot be abused
via
long strings, and whether $maxParamCount alone could mitigate those
risks
?
And now by thinking about it more, neither I could identify any
specific
vulnerability that
would become possible by not enforcing the upper limit. In the
previous
iteration
of the RFC, limiting the length was more useful, because parsing would
have been
a more resource intensive operation due to the requirements of the old
"array API".
The operations that are performed now during parsing are cheap, so as
far
as I can see,
it's possible to get rid of this option if no one can come up with a
good
enough use-case.
Just after sending my previous reply, I realized that even if parsing
long
query strings
isn't an expensive operation on its own, the rest of the operations
supported by
QueryParams may be. For example, sorting by long keys can cause
significant
slowdown.
(To be fair: I haven't done any measurements yet). And in the light of
the
recent CVEs,
increased memory consumption can cause troubles, so IMO an
automatically
enforced
maximum length can still be useful.
Let me get this out of the way first, because I find it easy to give an
answer here and it seems like this point is important to you with the
follow-up. I'll reply separately on the other points.
To the quoted point:
Checking the length manually is easy to do and in some cases (e.g. when
parsing the `$_SERVER['REQUEST_URI']`) the length is already bounded by
a gateway in front FPM.
With regard to “increased memory usage” bullet point (1) in my previous
email was already in anticipation of the recent security releases and I
checked with the others in the security team before giving my answer.
The most important part is that an attacker is not able to exceed the
(new) hard limit and more generally, an attacker should be unable to
cause “superlinear” memory consumption. As I had mentioned in that
earlier email, the input query string is mostly just “copied as is” with
some overhead added for house keeping of each individual entry. Thus a
query string consisting of just `&` is the extreme case. And that is
already limited by a maximum number of parameters.
Similarly sorting should also be O(n * log n) in the number of
parameters, which is already limited during input time. Each individual
comparison is bounded by key length, making this overall a O(l * log n)
with l being the input length. If necessary a user can also verify the
number of parsed elements themselves before sorting - but I don't expect
that to be necessary, there are already much more expensive operations
that are regularly performed on user input. Parsing itself should be
linear in the length of the input string.
Best regards
Tim Düsterhus
