Any security difference storing images outside root vs "deny from all"?

cretaceous

Are there any significant security pros and cons re. storing images outside root, versus storing them in root but in a directory with htaccess set to "deny from all"?

In both cases files will then be served with a script.

Thanks

sneakyimp

It's not hard to imagine a situation where the apache configuration gets altered and somehow your .htaccess file ends up getting ignored. In this case the "deny from all" in the .htaccess file would do nothing to help you. This might happen if someone were to recompile and install perhaps? Or if you had to move the code to a new server? Or perhaps if your domain changed?

If the images are outside your web root, then the default would be that these images are NOT accessible (unless your web root changes to include that folder, which seems unlikely to me).

In my opinion, it's much better practice to keep any protected assets OUTSIDE of the web root.

Weedpacket

sneakyimp wrote:
It's not hard to imagine a situation where the apache configuration gets altered and somehow your .htaccess file ends up getting ignored.

Especially since Apache's recommendation is to avoid using .htaccess in the first place if you can use .htconfig instead; it's possible to disable .htaccess completely (which is a performance boost because it means Apache no longer has to search the directory tree on every request).

cretaceous

Ok take you point..
If htaccess is disabled how would you get mod_rewrite functionality?

johanafm

I havn't used Apache in a while myself, but you should probably be able to deal with this using the docs: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html

This module operates on the full URLs (including the path-info part) both in per-server context (httpd.conf) and per-directory context (.htaccess)

and additionally

By default, mod_rewrite configuration settings from the main server context are not inherited by virtual hosts. To make the main server settings apply to virtual hosts, you must place the following directives in each <VirtualHost> section:

sneakyimp

cretaceous;11044925 wrote:
Ok take you point..
If htaccess is disabled how would you get mod_rewrite functionality?

I have a vague recollection of simply copying and pasting the .htaccess directives into an apache conf file corresponding to whatever domain is involved. E.g.:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /home/example/public
    ServerAdmin admin@example.com


# mod_rewrite rules for CodeIgniter
RewriteEngine On
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

</VirtualHost>

Derokorian

sneakyimp;11044937 wrote:
I have a vague recollection of simply copying and pasting the .htaccess directives into an apache conf file corresponding to whatever domain is involved. E.g.:
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /home/example/public
    ServerAdmin admin@example.com


# mod_rewrite rules for CodeIgniter
RewriteEngine On
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

</VirtualHost>

I'd like to point out there's a small downside to this. Changes to the rewrite rules require an apache restart to reparse the conf. On the plus side, it doesn't have to refind and reparse the rules on every request.

sneakyimp

Derokorian;11044943 wrote:
I'd like to point out there's a small downside to this. Changes to the rewrite rules require an apache restart to reparse the conf. On the plus side, it doesn't have to refind and reparse the rules on every request.

An excellent point. It also requires root-level access to implement usually. It's my understanding that it can significantly improve performance. I also think that if you have complicated and frequently-changing mod_rewrite rules then you are doing something wrong.

cretaceous

Ah.. ok.. lots of food for thought here.. thanks - really informative stuff!

Weedpacket

Oh, and one more difference between httpd.conf and .htaccess is that the former lies outside the document root.

dalecosp

Derokorian;11044943 wrote:
I'd like to point out there's a small downside to this. Changes to the rewrite rules require an apache restart to reparse the conf. On the plus side, it doesn't have to refind and reparse the rules on every request.

True, to a point; a "graceful" restart will do the trick rather than a complete stop/start cycle; nonetheless, that's a root-level command and not something that you might be able to do on a whim even if you are root for a very busy box (it would cease serving while finishing its current requests; that shouldn't take too long but do you ever really want your top-tier website to be down at all? --- not that I'm TOO likely to be working for Google anytime soon ...)

johanafm

Derokorian;11044943 wrote:
Changes to the rewrite rules require an apache restart to reparse the conf.

edit: oh, should perhaps have read all posts first…
Not according to their documentation at http://httpd.apache.org/docs/2.2/stopping.html

Graceful Restart

Signal: USR1
apachectl -k graceful
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.

I havn't tried this with Apache, but I know it works well in nginx (nginx -s reload which uses HUP). Just make sure you verify that all config files are valid before reloading them. Otherwise your web server will come to a screetching halt.

sneakyimp;11044947 wrote:
It also requires root-level access to implement usually

You'd only need to let the user execute "apachectl -k restart" as root. Not sure if this would differ across shells, distros, unix flavors etc, but adding the following to /etc/sudoers should be enough

%the-user ALL:(root) /path/to/apachectl -k graceful

where the-user actually is the user's group, but you may use a group containing only one single person. This way you do not give the user root access. You only allow them to run "apachectl -k graceful" as root.

ayoub

Thanks for the reply... but I cant just re-install the system for many reasons.

Would chowning each dir excluding home as user root work?