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.
Conversation
A nice static analysis tool for catching these vulnerabilities and others:
github.com/yandex/gixy
GitHub workflow for checking it in pushes/pull requests:
github.com/GrapheneOS/rel
Applies to more nginx directives than I realized. HTTP/2 framing basically acts as a mitigation.
1
1
13
I've read most of the official nginx documentation and I can't recall seeing any mentions of these issues. Meanwhile, they heavily encourage using location blocks instead of using `if` which makes it way harder to avoid these problems. Oh well, now I found a tool to catch them...
1
1
gixy suggests changing your location blocks to capture non-whitespace characters. Not always an option and not very clean. Seems easiest to use top-level `if` checks with $request_uri for regex-based redirects since you don't get header injection vulnerabilities from `return $1`.
Replying to
Pretty trivial to exploit a lot of configurations that are advised in popular articles, blog posts, StackOverflow, etc. for HTTP/1.1 because headers are separated by newlines and nginx happily writes out newlines via return, etc. coming from $uri, location block captures, etc.
1
I can't understand how they could possibly not consider it their responsibility to check for newlines in `return $data`, etc. and escape it instead of letting that result in injecting headers. Software is just so unbelievably bad sometimes. Don't know why I expect any better.
1
1
3
The positive side is that HTTP/2 stops most of these problems (at least with return, rewrite, add_header, etc.) from being exploitable based on my testing. The binary framing around the headers ends up resulting in it breaking the request instead of being able to inject headers.
1
3