Does disabling .htaccess improve security?

Question

I have a new WordPress website that has been installed on a server not managed by me. Its admin has enforced a few rules in order to increase security, I'm not entirely aware of its entirety but it includes:

• Placing apache's www folder in a separate, noexec partition
• Running apache as a user with read-only access on the folders
• open_basedir disabling access to folders above WP's structure
• Permissions (640 or 740 if I recall correctly) on most folders and subfolders (except wp-content/uploads/ and a couple others). Whenever a new plugin needs to be installed, updates applied or changes made to the files, a script applies recursively more relaxed permissions temporarily.
• Apache ignores .htaccess files.

I have not defined those policies and I'm not aware of its efficacy. However, the last item (disabling .htaccess) is causing me at least two problems:

1. Stops "pretty permalinks" from working (the user-friendly URL rewrites).
2. Prevents the BulletProof plugin from working (basically a collection of .htaccess directives that are supposed to protect WordPress against XSS, RFI, CRLF, CSRF, Base64, Code Injection and SQL Injection hacking attempts, and prevent access to files such as readmes that might give away WP's versions, other config files, php .ini files and directories listings).

My question is: does disabling .htaccess present some advantage from security viewpoint that might justify losing those above listed points?

Answer 1

Disabling .htaccess doesn't in itself provide any additional security benefit to your website. As @Xander mentioned the primary reason I've seen .htaccess disabled is performance (although I would suspect the performance improvement is negligible in many cases).

However from the hosts perspective it could provide some security benefit, in that it may help protect the host (and any other users on the box) from you. If you the "untrained" user misconfigure a directive in .htaccess it could cause problems for other things running on the box. And in that sense it also helps prevent you from accidentally compromising your own site.

Now whether this is of any practical value, given that there are better ways to handle this, is an entirely different question.

In addition to the options mentioned by @gowenfawr. You could ask your host to add the configuration directives that you want in the .htaccess directly to the server config of your site. That would allow them to confirm that the configuration won't cause a security compromise.

Answer 2

According to the Apache manual "there are two reasons" why .htaccess files should not be used: Server Performance and Server Security. (I've not copied their extensive explanations here for brevity.) See: When (not) to use .htaccess files

In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things.

Additionally

1. Server performance The manual recommends always making changes in the server configuration file (or an included configuration file). The host in your case could easily apply any changes you need to have happen for security directly to the server configuration. When .htaccess is allowed the server has to check all directories on the server for directives. Some of bloated blogs and plug-ins (like TinyMCE) that contain thousands of folders can dramatically decrease server performance over hundreds of vhosts.

2. Server security - Disabling .htaccess affords the host exclusive control over the server configuration since .htaccess is after all used to overwrite controls set in httpd.conf. If someone adds a line maliciously or without thinking about the repercussions (AddType application/x-httpd-php .pdf), they could open a gateway into the server which would allow the attacker to now target the host machine, cluster, or cloud where the exploited vhost resides. Most of the time .htaccess files can be written directly to the server by someone with simple ftp-only access. On many of the insecure systems I've been on from global shared hosting companies read/write access is granted to the web root (and most subdirectories) where a .htaccess file could reside. Most "secure" CMS systems allow the uploading of PDF files whereas they drop php upload attempts.

How should it be done?

1. Ideally the host would grant some overrides. This could allow things like mod_rewrite, mod_auth, mod_deflate, and mod_gzip.
2. The host should restrict uploads to the server to SFTP or FTP over SSH. (If their concern is someone pulling passwords and logins from clear text.)
3. The host should only grant overrides to things that need to be overwritten. (Custom 404 errors, mod_rewrite directives, etc.) This should go without saying, but the host should not provide overrides to all things in allowable because of the nature of .htaccess and it's capabilities in overwriting to the httpd.conf file.
4. The host should implement something like IPtables to take care of brute force attempts.
5. The host can allow overrides in a custom file that is not .htaccess (they can rename the file with AccessFileName), meaning they can all the file .accesscfg or something an automated script wouldn't write on injection. If the server isn't looking for .htaccess then an automatic payload would not be executed if someone were to add a file named as such.
6. The host should clearly declare why they are doing what they are doing, and what they have done, to not waste their customer's time and their own resources by resolving trouble tickets for issues that they have created.

Why would a host go about blocking .htaccess? Paranoia seems like a good reason, however after seeing 10-20 new [lazy] questions daily on stackoverflow.com about .htaccess and mod_rewrite with people causing 500 internal server errors and never-ending redirect sequences; and having first-hand rewritten several very poorly executed 100+ line .htaccess files inherited from past development teams ("professionals") to see 300-500% performance gains on individual vhosts, I can see why on a larger scale this would seem like a more logical thing to do. It's not the answer for everyone, but when there might be 300+ hosts in a virtual cluster and they're trying to gauge performance overall, it's a lot harder to tell whether all of the repeated traffic is a bad .htaccess file with multiple redirects in sequence, or a legitimate attack.

Additionally most hosts have slashed budgets in terms of support (some charge extra for it now, even on managed dedicated hosting plans), so when someone calls because their vhost or VPS is performing poorly, the host has to start an investigation in the cluster or on the box to determine where all of the resources are going. This could be 20 customers at once with the same complaint.

If it were my server, I would ask the admins for a few overrides in your vhost, and show them what you're doing. Show them why it's a bad idea for them not to allow you to make edits. They might even offer to make the changes permanent in your vhost which would speed up the whole experience. It's likely a knee jerk reaction to stop a lot of repeated issues with server performance (not so much security).

If it was a real security issue, they would likely block Wordpress altogether. On another note, remember to rename your admin account to something else.

Answer 3

As the author of the htshells project, I thought it might be appropriate to chime in here. It is my professional opinion as both a system administrator and a penetration tester, that you should disable .htaccess, but neither security nor performance is the primary reason for this;

It seems that some of the responses are focusing on the ability to overwrite an existing .htaccess file, which is somewhat flawed. It's usually a matter of creating a .htaccess file somewhere. Imagine, for example, that you allow file uploads to your website, and the application correctly filters file types, but missed the .htaccess file. A file upload later you have remote code execution. This is only marginally different from uploading a PHP file, but the ability to reconfigure parts of Apache on the fly is valuable to an attacker.

As there is no reason you cannot place your .htaccess directives into your Apache config, there should be no real need for .htaccess files in production environment. Although I think "What should my AllowOverride directive look like?" might be a better question, if you must support .htaccess files (i.e.: shared hosting).

Answer 4

Disabling .htaccess does provide some protections. If an attacker can somehow modify .htaccess files in the web root, they can modify the server configuration, for example adding a handler so that .txt files are processed by PHP. If your server allows them to upload .txt files but not .php files, boom, they've just found a way to bootstrap themselves into executing code.

To look at it from your host's point of view, if he's hosting for 100 people, 95 of them have no need for .htaccess at all and 4 of them want to do sparkly shiny stuff with it. At best 1 out of 100 (you) is going to want to do anything with it to improve your security. So is losing .htaccess justified? Not for you, but by the numbers, it does make sense for the host.

Therefore you've got three options:

1. Persuade your hoster to make an exception for you
2. Accept the limitations your hoster is imposing upon you
3. Find a new host, or run your own host, both probably being more expensive than your current setup

EDIT 6/3:

As my description (in comments below) of using .htaccess to break in with cgi-bin has been described as "absolutely no content", I provide the following link to an actual exploit that embodies this exact attack route.

Attacking Webservers via .htaccess

htshells Project Page

(In fact, it somewhat ingeniously goes one step further; it maps the .htaccess file itself for cgi-bin execution and embeds the malicious code in the very file that's being rewritten to allow the malicious code to execute. How deliciously meta!)

So, I'm sorry, but yes, .htaccess can be abused as I've described; it has been, it will be. Santayana's not just some old guy who plays a mean guitar. And if you need still more cases for disabling .htaccess, they aren't hard to find:

Google "htaccess hacked"