What are NGINX reverse proxy users doing to prevent HTTP Request smuggling?

[Sai Vishnu Soudri (ssoudri)]

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 at nginx.org on behalf of mdounin at 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 at nginx.org
    http://mailman.nginx.org/mailman/listinfo/nginx