fix: problematic parsing leniency in parsing chunk extensions

[JeppW]

Stop allowing newline characters in chunk extensions. This can cause request smuggling issues with some reverse proxies.

Reference: https://grenfeldt.dev/2021/10/08/gunicorn-20.1.0-public-disclosure-of-request-smuggling/

[pajod]

Any thoughts on singling out just the newline, among multiple characters that could conceivably cause trouble behind a robustdangerous proxy?

[JeppW]

AFAIK only the newline has ever been shown to be exploitable in practice. Perhaps we should disallow \r as well, it seems plausible that a proxy could misinterpret \rX as a line terminator. Other than that, I think further validation would just be unnecessary overhead.

[JeppW]

I added the \r as we agreed.

[benoitc]

On hwich specification is based this change?

[pajod]

@benoitc You can reference the 2022 one. Control chars were never supposed to appear in chunk extensions:
https://datatracker.ietf.org/doc/html/rfc2068#section-3.6
https://datatracker.ietf.org/doc/html/rfc2616#section-3.6.1
https://datatracker.ietf.org/doc/html/rfc7230#section-4.1.1
https://datatracker.ietf.org/doc/html/rfc9112#section-7.1.1

The choice of \r\n (and possibly \0) is arbitrary and based on bugs in real-world software, but similar considerations as in rfc9110 section 5.5 apply.

[pajod]

(only) CR rejected since bdb2ebd