Opened 5 years ago
Closed 5 years ago
#1810 closed enhancement (wontfix)
Complex UX - Configuration Pitfalls ("Passing uncontrolled requests to PHP")
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | major | Milestone: | |
Component: | nginx-core | Version: | 1.17.x |
Keywords: | Cc: | ||
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 |
Description
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
Thank you for your opinion. Configuration of nginx is designed to allow passing requests to FastCGI applications regardless of the fact if appropriate files exists or not, and this allows passing requests, for example, to different servers. If this is secure or not in your particular setup - not nginx's business, and it's up to you to configure nginx appropriately if for some reason you think it's not.