Conversation

FWIW: It's *very* entertaining to read the nginx source code (full of state machines that try to do minimal work during parsing) and look at what hilarious variants nginx will still recognize as valid HTTP. Often only one letter of a keyword will be checked.

Quote Tweet

Halvar Flake

@halvarflake

Oct 31, 2021

Anyone chiding other developers for not using state machines should be first forced to read the nginx source code followed by writing an HTML parser in verilog.

137

Replying to

last time i looked at it, it seemed stricter in places than i (as a security engineer trying to write an exploit) would like, which was comforting to me (as a security engineer trying to make sure things are less exploitable)

Replying to

and

It recently got a lot stricter in many cases in the mainline branch but it's not yet in the LTS branch that's updated to a new major version yearly. Still has this issue: github.com/yandex/gixy/bl.

github.com

gixy/httpsplitting.md at master · yandex/gixy

Nginx configuration static analyzer. Contribute to yandex/gixy development by creating an account on GitHub.

Replying to

and

wow, this repository is really useful, thanks for sharing

Replying to

and

Location blocks work on unescaped URIs (they essentially operate on the processed $uri rather than original $request_uri) so using a regex capture and passing it to return, etc. is insecure... and that's very common, all over places like StackOverflow. No warning in nginx docs.

7:03 PM · Oct 31, 2021Twitter Web App

Replying to

and

HTTP splitting only happens with HTTP/1 so HTTP/2 actually fixes that by turning it into a framing error instead. It's still really bad that nginx doesn't escape input to return, etc. and design of the configuration strongly encourages you to implicitly do regex captures on $uri.

Replying to

and

Changes from 1.21 mainline branch forbidding spaces and control characters in request, header names and the host header are finally in a stable release with 1.22. Still going to be many years before most deployments have the vulnerabilities fixed since they didn't assign CVEs.

Replying to

and

i had some rudimentary scripts for this kind of source-sink analysis of user-controlled data making it directly into a HTTP response (or an SSRF target) but i'm excited to try existing tooling like this instead

Replying to

and

gixy works really well. GrapheneOS has it set up via a GitHub workflow for all of our nginx configurations across our sites/services: github.com/GrapheneOS/Att Sometimes find add_header warning annoying because I'm sometimes intentionally dropping a header from the outer scope.