
Apache Performance: Disable .htaccess here's why - ashitlerferad
https://haydenjames.io/disable-htaccess-apache-performance/
======
jarofgreen
I wrote a small script a while back to collect all the rules from various
.htaccess files into one file you can then just include in your main config -
might be useful for some. [https://github.com/JMB-Technology-
Limited/ApacheHtaccessIn](https://github.com/JMB-Technology-
Limited/ApacheHtaccessIn) Can then work with .htaccess files (a lot of third
party apps use them) but automatically rewrite them into your main config for
performance on production.

~~~
kyriakos
that's a good idea - thanks for sharing.

------
hannob
Isn't the support for htaccess basically one of the only reasons one would use
apache in favor of nginx? I.e. that you can provide users some configuration
possibilities on a multiuser system?

I run some servers with an apache/php/mysql configuration, we looked multiple
times into nginx and that was always the problem: A user wouldn't be able to
install any standard CMS without asking the admins for changes to the server
config.

~~~
PuffinBlue
Did you look at the 'include' directive in Nginx?

I'm not sure about the security implications as I use this just for servers I
control, but you can use a (just example naming) nginx.conf file in the
website root, and use the 'include' directive in the main config file to read
from that.

That's how I use Wordpress with Nginx to automatically write things like
Yoast's Wordpress SEO or iThemes Security rules.

Something like:

    
    
        include /var/www/domain/htdocs/nginx.conf;
    

Seems like there would be similar security concerns to using a .htaccess file
but I've not looked into that in any detail.

~~~
andwur
If the included file is writable by the PHP user then I would say that poses a
reasonably high security risk; potential privesc, information disclosure, RCE.
Of course an attacker would need the ability to manipulate local files as the
PHP user, but that isn't much of a stretch.

Under a typical install, e.g. Debian, Ubuntu, etc, nginx parses the
configuration files as root thus any exploit of the config parser gains full
root access as the nginx master process doesn't drop caps.

Depending on where the include line is placed it may be possible for an
attacker to create server blocks allowing them to execute arbitrary PHP by
permitting PHP execution from a directory with PHP write access, e.g. `wp-
upload`. Assisting exfiltration of data by allowing easy remote access to the
filesystem. Possibly proxy all traffic through an attacker controlled script
or host. Exposing local services to the outside world.

I'm sure there's plenty of other interesting little attacks possible if given
enough time to play around with it.

If at all possible I would avoid permitting unprivileged r|w access to nginx
configuration files.

~~~
PuffinBlue
> If the included file is writable by the PHP user then I would say that poses
> a reasonably high security risk

It wouldn't be, just writable by the ordinary user. That pretty much negates
the rest of what you said except for...

> Of course an attacker would need the ability to manipulate local files as
> the PHP user, but that isn't much of a stretch.

If that's happening you've got far worse things going on than having a
nginx.conf file around.

------
Jach
Anyone profiled a before/after for this?

~~~
duskwuff
Yes. The difference is pretty minor; it's a difference of a couple 'stat'
calls per request, all of which are guaranteed to be cached in the kernel. If
you're serving a lot of static content, it _might_ start to be noticeable, but
at that point you're probably better off using a different web server for that
content. (Or putting it on a CDN.)

~~~
lucb1e
I was thinking the same about OS caching, but since the author didn't actually
try that out it's still uncertain and a fairly useless article...

------
rando832
A little inaccurate, .htaccess is disabled by default (2.3.9 and later), so
you do not need "AllowOverride None" unless it's enabled somewhere else.

------
sdx23
Also some of the reasons why nginx doesn't support .htaccess files to begin
with.

