0

So there are the following two posts (among others) that say 755 is okay for the sites/default/files directory:

  1. What are the recommended directory permissions?
  2. Confusion about files permission

I took over a site that was hacked (due to missing a security update and improper Drupal/server configurations), whereby the hacker setup a generic form to download files (.js, .php, etc.) to the default files folder, then presumably they'd be able to execute them by setting up another page on the site that actually loads the file.

They did this by commandeering a site with admin privileges. And while I could not find an actual file they downloaded to the files directory, they did wind up altering the company's homepage with a "You've been hacked" message and an image of a country's flag.

Now to my questions:

  1. Why have 755 on sites/default/files directory (and sub-directories) instead of 744? Isn't the files folder by definition for user files and system caching files? To flip the question around, is there any legitimate reason to allow "x" for the group/other users?
  2. Is the new default .htaccess file (shown below for reference) that gets written to sites/default/files "secure enough" that even if a user hacks the front end or database, they can't really cause much havoc? If not, is there something that can be done to prevent all executables from running within /sites/default/files?

Here's the .htaccess file written by Drupal:

# Turn off all options we don't need.
Options None
Options +FollowSymLinks
# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
# Override the handler again if we're run later in the evaluation list.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>
# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
php_flag engine off
</IfModule>
2

Why have 755 on sites/default/files directory (and sub-directories) instead of 744? Isn't the files folder by definition for user files and system caching files? To flip the question around, is there any legitimate reason to allow "x" for the group/other users?

Without the "x" being set for a directory, the group/user will not be able to look inside the directory. So you usually want the "x" bit set for group/users for the directory in order to be able to examine these in the CLI without being root.

Is the new default .htaccess file (shown below for reference) that gets written to sites/default/files "secure enough" that even if a user hacks the front end or database, they can't really cause much havoc?

IMHO, the Drupal .htaccess is adequate for preventing executables downloaded to the upload from being executed.

However, having this file in place does not protect you from front-end or database exploits. And attackers gaining access to execute PHP from the database can remove or replace it.

So you also want to prevent PHP injected into the datebase from being executed. You do this by removing the core PHP module. Do this:

rm -rf modules/php/

You should never enable this misfeature (it has been removed from core in D8), but by physically removing out, you eliminate the risk of somebody making a succesful SQL injection exploit also being able to execute PHP.

Provided you don't use it (and you shouldn't), and it is already disabled, removing it has no side-effects.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.