Conversation

twitter.com/DanielMicay/st Most of these security issues are indirectly resolved in a stable nginx release with 1.22.0. Most fixes are from the 1.21.1 mainline release in July 2021. However, they weren't marked or treated as security fixes so the 1.20 branch didn't get backports.
Quote Tweet
I love how using `return $uri` instead of `return $request_uri` is a vulnerability for nginx configuration since they don't sanitize the input and allow it to inject data into the headers via newlines. Alternatively, capturing/using any variables in location blocks with newlines.
Show this thread
Replying to
The configuration directives are still vulnerable and can still be easily used in a way that allows an attacker to inject headers for HTTP/1.1. Their fixes forbid spaces and control characters in request URI, header names and Host header so most sources of tainted data are gone.
1
Previously, incredibly pervasive nginx configurations simply using a regex location block with a capture like (.*) and then passing it to one of many directives like return were vulnerable to header injection. Many answers on Stack Overflow, blog posts, etc. have vulnerable code.
1
You can find many examples of Stack Overflow answers proposing vulnerable configurations with simple searches: "return 301 $uri" site:stackoverflow.com These vulnerabilities are pervasive in nginx configurations and they strangely don't mention this in any official docs.
2
2
nginx configs using directives like return with $uri or location block URI are almost all vulnerable. Includes using components of URI via regex captures in location blocks or if directives without filtering newlines, etc. Sadly many use nginx via frozen Linux distro packages.
Replying to
Yeah. I don't twiddle my nginx configs often so someone asked in passing and I advised them wrong hitting this bug. They were saved by nixos running it through gixy though.