Permissions for images

[csdude55]

I have a /cache/ directory where users can upload images using a Perl script that I've written. Usually those images are uploaded, then resized and shown back to the webpage as a preview, then moved to a different directory for long term storage where they will be viewed regularly. But if they abandon the page before submitting then the images aren't moved and stay in /cache/, so I have a cron to delete files from /cache/ that are older than 24 hours.

After someone recently uploaded a PHP script that slid through the cracks (I have a separate thread on this), I'm tightening up security.

Right now I have all files uploaded to this directory set to permission 0666, so I was surprised that they could still execute their PHP script.

Would it be more appropriate for the directory and image permissions to be set to 0600 instead of 0666? Or would that add any further security at all?

Any other suggestions on permanently preventing anything in this directory from being executed? Is there an .htaccess hack to turn off execution?

[lucy24]

Is there an .htaccess hack to turn off execution?

Pretty sure you can tell it to interpret php files as plain text, so all they get is the text content of their own php script thrown back into their faces. (With a further vague idea that I once achieved this by accident.) AddType? AddOutputFilter? AddHandler?

:: detour to docs ::

:: further detour to test site ::

You could always say
RemoveHandler .php
in this directory's htaccess--assuming there will never be any intentional .php files either directly in, or called by files in, this directory--though I strongly suspect there is a more elegant solution.

[csdude55]

In retrospect, since the crack attempt also uploaded an .htaccess file... I guess this wouldn't work as I was thinking. They could potentially overwrite my .htaccess.

I did some research and found that I could add this to Apache 2.4's configuration:

<Directory /home/example/www/cache>
 <FilesMatch "\.(?i:php|htaccess)$">
  Require all denied
 </FilesMatch>
</Directory>

I don't understand the ?i, though. I was trying to find a good way to test if it simply did NOT match jpe?g|png|gif|bmp, but that's a bit more complicated and I'm not sure if it would work right.

Do you think this would be better?

<Directory /home/example/www/cache>
 RemoveHandler .php
</Directory>

I suspect that it's faster to process than using FilesMatch, but I think that Require all denied would return a 403 Forbidden status.

[lucy24]

I don't understand the ?i, though.

Doesn't it mean “what follows is case-insensitive”?

Your server should already have a global rule that says something like
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>
but note that this doesn't in any way prevent people from uploading a file (by FTP-or-similar); it just prevents them from viewing your htaccess/htpasswd via an ordinary HTTP request.

<tangent>
In fact one directory on my test site has a supplementary htaccess that reads in full

<FilesMatch "^\.ht">
Require all granted
</FilesMatch>

# scary, huh?

I made it once to amuse someone hereabouts, though I no longer remember the full backstory. The point was that you can enter example.com/directory/.htaccess in your browser ... and actually see the htaccess.
</tangent>

Are the image files uploaded via a PUT command? If so, you may want a <Limit> or <LimitExcept> envelope placed inside a <FilesMatch> envelope--or possibly vice versa, not sure if it matters except from the Personal Coding Style angle. The effect of the nest would be to say "only allow PUT requests if the filetype is {list of images}". Horse's Mouth says

A <LimitExcept> section should always be used in preference to a <Limit> section when restricting access, since a <LimitExcept> section provides protection against arbitrary methods.

which is a good point. As an alternative to FilesMatch, you could set an environmental variable--in fact this is one of Apache's first examples for the use of a SetEnvIf directive--and then say "Require env image" or whatever you choose to call it.