What are NGINX reverse proxy users doing to prevent HTTP Request smuggling?
Sai Vishnu Soudri (ssoudri)
ssoudri at cisco.com
Tue Dec 14 14:50:19 UTC 2021
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.
Sai Vishnu Soudri
On 14/12/21, 3:48 AM, "nginx on behalf of Maxim Dounin" <nginx-bounces at nginx.org on behalf of mdounin at mdounin.ru> wrote:
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
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
Probably the only thing to care about are inherently insecure
settings like "ignore_invalid_headers off;" and
"underscores_in_headers on;". These are better to be kept in
their default values unless you understand possible implications
in your particular setup.
nginx mailing list
nginx at nginx.org
More information about the nginx