Complex UX - Configuration Pitfalls ("Passing uncontrolled requests to PHP")
|Reported by:||Owned by:|
|uname -a:||Linux www2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64 GNU/Linux|
|nginx -V:||nginx version: nginx/1.10.3|
Is: Problematic User-Experience (UX) for administrators
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php lists common pitfalls, that could result in remote code execution (e.g. https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#passing-uncontrolled-requests-to-php). Referring to the OWASP-Project (OWASP Top-10 2017) "Security Misconfiguration" and "Broken Access Control" are among the most critical web application security risks.
Again, regarding "Passing uncontrolled requests to PHP" the docs are proposing 4-different, working configurations without explicitly recommended a single one. Some configurations are problematic in certain setups ("The one caveat is that this workaround prevents you from using try_files to avoid PATH_INFO attacks. See Passing Uncontrolled Requests to PHP above for alternative ways to mitigate these attacks." - Paragraph "Using the try_files $uri directive with alias").
In addition, regarding "Proxy Everything", it is not intuitive clear to me, in what way the example for "Also GOOD" applies the protections needed. (E.g. what happens, if somebody reorders the two location directives by accident?)
Should: Better UX / Usable Security
By design, nginx's configuration should avoid known pitfalls. Regarding
"Passing uncontrolled requests to PHP" this could - for example - result in deprecating, fastcgi_pass and introducing fastcgi_pass_harmful and fastcgi_pass_checked, with the first one having the old fastcgi_pass effect and fastcgi_pass_checked applying protection according to one of the 4 ways proposed.
In addition, the documentation should recommend one way explicitly, that "just works" in 99% of all cases. Referencing others is fine, but users need to be guided.
In addition, nginx should refuse to start, if commonly known, insecure patterns exists in the configuration. Staring using a additional command line parameter should be possible, though