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`.
1
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.
Replying to
Speaking of HTTP. I have an interesting feature suggestion.
You could try something, like an HTTPS Everywhere, but systemwide.
Like all unencrypted traffic of the phone would be blocked