3 ms·
A lot of these look like not-so-great design choices in the way nginx is configured and how it handles paths. Sometimes the behavior that leads to security pro
by chmod775 6y ago
A lot of these look like not-so-great design choices in the way nginx is configured and how it handles paths.
Sometimes the behavior that leads to security problems here may be desirable, but it probably shouldn't be the default.
For instance "location /api {" probably shouldn't match "/api../" by default. Instead it should be treated like a file system would. The "prefix" matching should be
a different configuration option like "prefix /api {".
- bawolff 6y agoIf someone does /api/../whatever, does nginx normalize that away automatically? Otherwise it seems like you could just do the attack directly (yes most clients wont let you make such a request, but that is easy to work around)
- bungle 6y agoIt does, but Nginx normalization is a bit dummy. It doesn't take into account the reserved chars for example.
- c0l0 6y agoIt's one of the shortcomings that I've come to loathe in nginx's declarative configuration language (and also other software products - Apache httpd is just as guilty). Everything just looks so innocent - but the devil is often in the details. So much implied nuance that you have to keep in mind when reading and especially when writing it. Sure it's expressive and also convenient (the latter at least as long as your configuration stays relatively simple), but something like varnish's imperative VCL that offers very little built-in magic sure is easier to reason about. I have come to consider that a feature.
- mhitza 6y agoWouldn't it be nice if all these programs started using at some point a proper embedded language for configuration? Lua, Tcl, Guile. I'd take any of those instead of the ad-hoc, declarative - but no really - languages that Apache and nginx use.
- feanaro 6y agoThat just seems like an even greater nightmare to me. Soon you would have to learn to read and understand a custom program in a Turing-complete language for each and every installation. The proper solution is a DSL, just a better DSl. Or perhaps a DSL embedded in something like dhall <https://dhall-lang.org/ https://dhall-lang.org/>, but definitely not a general-purpose programming language.
- mhitza 6y agoI was gonna consider including Dhall in my list, but then again nginx configuration has support for if statements. And from my past experience with HCL, sometimes a proper embedded programming language is better than whatever crazy DSL some developers can envision (see for loops in HCL)
- kevin_thibedeau 6y agoTcl is meant to be embedded for scripting and it can be made non-Turing complete by stripping away all but the bare minimum of commands. There is a built in mechanism for sandboxing untrusted input. If can easily be a safe, bullet proof configuration language.
- PowerBar 6y agoWhether JavaScript qualifies as a "proper embedded language" is up for debate, but nginx does support it for dynamic request handling. https://www.nginx.com/blog/introduction-nginscript/ https://www.nginx.com/blog/introduction-nginscript/
- mhitza 6y agoThat link is interesting for two reasons. First because of the feature you mentioned, and second because there is apparently a community lua module (nginx module implementation must be interesting if you can just attach a deeply embedded language via a module) Somehow this didn't pop up on our search results (a couple of years back) when we were dealing with some tricky redirection patterns we had to implement. Would have made things much easier.
- iforgotpassword 6y agoAgree. Nginx is probably a thousand times more powerful than lighttpd, but while setting up php with fastcgi on the latter was straight forward and easy to understand, with nginx you need a convoluted mess of includes, location directives, setting variables, then handling 404 is broken, there are ten different tutorials on how to do this and nine of them are wrong or open security holes and then you feel like a complete idiot.
- amenod 6y agoAgree. And there are other questionable design choices in this project too. by pet-peeve is an omission of `.htaccess`-like mechanism. There is even a page they have dedicated to this [0], where instead of looking at their users' problems and finding a suitable solution (like, only loading `.htaccess` every minute or when it changes), they argue that users don't actually have a use-case where they want to allow some limited configuration to 3rd parties. Someone even wrote a plugin that fixes that [1], but it is annoying (to say the least) that this is an option nginx developers say is "not needed" and "shouldn't be used". [0] https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/ https://www.nginx.com/resources/wiki/start/topics/examples/l... [1] https://github.com/e404/htaccess-for-nginx https://github.com/e404/htaccess-for-nginx