7

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?

3
  • 1
    Honestly, I think this is just some paranoia bullsh*t. If an attacker is able to infiltrate your security measures and gain access to your server, then modify your .htaccess then you have bigger problems. Same goes if your security depends on certain user-level Apache configurations so bad that you cannot trust your users with local .htaccess files, then you're a crappy sysadmin.
    – Adi
    May 29, 2013 at 18:56
  • From my experience, bulletproof is an overcommercialized solution which does not offer a lot of added security. They advertise that they protect against CSRF (I actually mailed them to ask this) while in fact they aren't. If I can make a suggestion have a look at Wordfence instead of BPS. At least they can offer a lot more than writing regexes for htaccess. May 29, 2013 at 19:18
  • The primary reason I've seen for removing htaccess is not security related at all, but for performance. If they haven't explicitly said they're removing it for security reasons, they may be removing it to keep you from shooting yourself in the foot perf-wise with thousands of complex rules.
    – Xander
    May 29, 2013 at 20:02

4 Answers 4

7

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.

5
  • 1
    "it also helps prevent you from accidentally compromising your own site" Then why not disable PHP, or MySQL. Since MySQL opens a door for SQL injection, and PHP opens a door for RFI.
    – Adi
    May 30, 2013 at 6:28
  • 1
    @Adnan Disabling .htaccess and leaving MySQL and PHP alone results in a workable system with 1 feature less. Disabling MySQL or PHP very likely makes the hosting service useless for very many customers.
    – l0b0
    May 30, 2013 at 8:53
  • 1
    @l0b0 My point is that the risk of you compromising your own site through .htaccess is very low compared to risks of opening a door for SQL injection and arbitrary code execution attacks.
    – Adi
    May 30, 2013 at 8:58
  • 2
    @Adnan I hoped that's what you meant, but security is not all-or-nothing. It's worth taking away hand guns even while nukes exist.
    – l0b0
    May 30, 2013 at 9:03
  • 2
    @Adnan, I agree but it's one less thing to worry about and it might help the admin sleep better at night.
    – matthew
    May 30, 2013 at 13:06
6

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.

7
  • 1
    Your second point "Server security" is a bit silly, don't you think? If someone has ftp access and can modify your .htaccess then they can also just directly upload a .php with all the nasties they want.
    – Adi
    May 30, 2013 at 8:51
  • @Adnan right, but if they write a backdoor and store it in some other file (where you wouldn't expect it) you're not likely to notice it without a deep thorough grep. Then you would have to know what you're looking for (eg eval(badstuffhere)). If I allow PHP to treat a PDF like a .php file, then upload a malicious payload in a PDF, the people on the server will likely not know. If they're not familiar with .htaccess then they would have no idea what they were looking at. When they open the PDF they would see a real PDF and not the backdoor. May 30, 2013 at 9:06
  • Additionally if someone gains access to .htaccess they can redirect all traffic off of the server where they can conduct their exploit. They could also do this with a php header() redirect as well, so even though it's a security risk, it's not limited to just .htaccess. The point is limiting the amount of risk on the box. May 30, 2013 at 9:09
  • @Adnan Additionally the attacker could redirect specific traffic to specific sites. So all traffic from Google go to an infected duplicate site (since they already have access to the php files). You would not have access to see what happened on the other server, or how long it's been going on. May 30, 2013 at 9:14
  • Reading down this list, matthew mentions in passing what I think is a very important point here - and which is more or less ignored by this answer. On a dedicated (i.e. non-shared webserver) anything which can be be imlpemented in .htaccess can be implemented in the central config file. Removing all overrides reduces the attack surface.
    – symcbean
    May 30, 2013 at 12:28
2

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).

1

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"

5
  • 1
    Mental -1! If the attacker already has access to modify your .htaccess he can just rename those .txt files to .php. I think you've failed to present a case for disabling .htaccess, security-wise.
    – Adi
    May 29, 2013 at 23:07
  • There's several dozen ways to skin a cat, and some of them fit the parameters I've described. Once upon a time the big problem with .htaccess files was leaving them writable to the http daemon process owner, which combined with bad cgi-bin (mental note: I'm getting old if I think in terms of cgi-bin) could allow modification where things like file rename or new file creation were not directly possible. So I appreciate your feedback but I respectfully disagree :)
    – gowenfawr
    May 30, 2013 at 3:50
  • I think you'd be a good politician. Your provided a 5 line comment with absolutely no content. The one thing I see is that you disagree, but you didn't back your argument with anything. So, now an actual -1 is due.
    – Adi
    May 30, 2013 at 6:03
  • My gut feeling tells me those random 100/95/1 numbers are way, way off. Do you know any Apache users which have never used .htaccess?
    – l0b0
    May 30, 2013 at 8:50
  • @l0b0 Indeed. Almost every CMS I know utilizes .htaccess for URL rewrite. I don't recall any webserver setup I'm encountered that didn't have an .htaccess file here and there.
    – Adi
    May 30, 2013 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .