Hi Maxim,

Thanks a lot for your reply. Just to clarify, by "There are no know vulnerabilities in nginx which make request smuggling possible" you mean after the 1.21.x release right?
I am using OpenResty and the latest version of OpenResty is based on mainline nginx core 1.19.9.

Currently, the approach I'm taking to mitigate HTTP Request Smuggling is blocking all incoming HTTP/1.1 requests. I was worried if incoming HTTP/2 requests would pose a vulnerability as nginx converts it before sending upstream, but with your reply I believe that should not be a problem anymore.

Since OpenResty is not able to leverage the new changes added in 1.21.x, do you suggest I continue with this approach till OpenResty can leverage the changes made in 1.21.x or is it mandatory to use 1.21.x and block HTTP/1.1 requests to prevent request smuggling.

Thank you,
Sai Vishnu Soudri

On 14/12/21, 3:48 AM, "nginx on behalf of Maxim Dounin" <nginx-bounces@nginx.org on behalf of mdounin@mdounin.ru> wrote:

Hello!

On Fri, Dec 10, 2021 at 11:46:48AM +0000, Sai Vishnu Soudri (ssoudri) wrote:

> Hi everyone,
>
> I'm a new NGINX user and I want to understand what NGINX reverse
> proxy users are doing to mitigate HTTP request smuggling
> vulnerability. I understand that NGINX does not support sending
> HTTP/2 requests upstream.
>
> Since the best way to prevent HTTP Request Smuggling is by
> sending HTTP/2 requests end to end. I believe NGINX when used as
> a reverse proxy could expose my backend server to HTTP request
> smuggling when it converts incoming HTTP/2 requests to HTTP/1.1
> before sending it upstream.
>
> Apart from the web application firewall (WAF) from NGINX App
> Protect, is there any other solution to tackle this
> vulnerability? I am relatively new to NGINX and reverse proxies,
> if NGINX or its users does have an alternate solution, please do
> share.

There are no know vulnerabilities in nginx which make request
smuggling possible. In particular, HTTP/2 code properly rejects
things like ":" or newlines in headers and checks the request body
length from the very start.

Further, various mitigations introduced in nginx 1.21.x are
believed to stop most, if not all, known attacks even assuming
various known vulnerabilities of a server in front of nginx and/or
behind nginx.

Probably the only thing to care about are inherently insecure
settings like "ignore_invalid_headers off;"[1] and
"underscores_in_headers on;"[2]. These are better to be kept in
their default values unless you understand possible implications
in your particular setup.

[1] http://nginx.org/r/ignore_invalid_headers
[2] http://nginx.org/r/underscores_in_headers

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx