On Mon, Mar 09, 2015 at 04:44:05PM +0200, Gena Makhomed wrote: > On 08.03.2015 22:50, Francis Daly wrote:
Hi there, > >>webpage http://wiki.nginx.org/Redmine has some security problems: > >> > >>1. All redmine config files are available for anybody in internet, > >>for example: https://redmine.example.com/config/database.yml > >>contains in plain text login and password for database connection. > > > >I don't think that one is an nginx problem. > Yes, this is not nginx problem. This is nginx configuration problem, > which provided at wiki.nginx.org as "drop in configuration" for redmine. I think that you are incorrect in your understanding of it as an nginx configuration problem, and as a drop-in configuration. > >From reading the redmine docs, it looks like the contents of the "root" > >directive directory should be whatever is in the distributed redmine > >public/ directory; not the entire installation including configuration. > > I am talk about configuration recommended > at webpage http://wiki.nginx.org/Redmine > not about "reading the redmine docs". But the user must have followed some documentation to install redmine in the first place; and if they unthinkingly install it into /var/www/redmine they are probably doing something wrong before nginx gets involved. I see instructions to install to /opt/redmine, and to /var/lib/redmine, and to /usr/share/redmine, and in each case they say to do something like ln -s /usr/share/redmine/public /var/www/redmine to have only the web-accessible content below /var/www/redmine. If the user really wants to install to /var/www/redmine, then they must modify the "root" directive (to be /var/www/redmine/public), as the words on the wiki page already say. I do not see this as an nginx-related security problem. > >And if /var/www/redmine does just have the public/ contents and the > >upstream servers reveal secret information, that would be their problem > >and not nginx's, I think. > > root /var/www/redmine; > try_files $uri @ruby; > > Request https://redmine.example.com/config/database.yml will be > processed by nginx, because file /var/www/redmine/config/database.yml > exists. For details - see manual about try_files directive in nginx. The file /var/www/redmine/config/database.yml should not exist. If the file /var/www/redmine/config/database.yml does exist and the above nginx configuration is used, then the user will find that no part of their redmine web-related installation will work, because all of the images and stylesheets and javascripts are inaccessible. Correspondingly, if the user has installed only web content below /var/www, then using a different "root" directive will cause that installation not to work. > >>3. Unsafe variable $http_host was used instead of safe one $host > > > >I'm not sure how $http_host is less safe than $host. It is proxy_pass'ed > >to the "real" redmine server as the Host header. That server must be > >able to handle it safely anyway, no? > > Such configuration allow to spoof nginx built-in server selection rules. > because nginx will use server name from request line, but will provide > to upstream completely different server name, from Host request header. It is true that $http_host is completely controlled by the client, and $host is mostly controlled by the client. It is true that they can have different values. I do not see that the difference is a security issue in this case. > So, $host must be used always with proxy_pass instead of $http_host. If the upstream server would do anything security-relevant with the Host: header that it gets from nginx, it would do exactly the same with the Host: header that it would get from the client directly, no? Also: I suspect that $http_host was there because if you run nginx on not-port-80, using $host will probably lose that information. The server{} has no "listen", so it will use port 80 or 8080 depending on the invoking user. The config that was there (probably) works under some circumstances, and fails under some others. It's fine to change it to another configuration which works under some different circumstances, but you should probably be aware that you are failing under different circumstances too. As as "example" config, it should be understood that it does not cover all circumstances. And the newer example config may be more suitable for more installations -- I'll let someone else count them, if they care. But I don't see how security is involved in the change. Cheers, f -- Francis Daly [email protected] _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
