Jump Menu : Content | Explore | Comments | Search | Home | Sitemap | Contact | Login | Access.

Improve Site Security by Protecting HTAccess Files

As you know, HTAccess files are powerful tools for manipulating site performance and functionality. Protecting your site’s HTAccess files is critical to maintaining a secure environment. Fortunately, preventing access to your HTAccess files is very easy. Let’s have a look..

Different Methods

If you search around the Web, you will probably find several different methods of protecting your HTAccess files. Here are a few examples, along with a bit of analysis:

Case-sensitive protection — As far as I know, this is the most widespread method of protecting HTAccess files. Very straightforward, this code will prevent anyone from accessing any file named precisely “.htaccess”. This is not ideal because the match is case sensitive. On certain systems, HTAccess files protected with this method may remain accessible via “HTACCESS”, for example.

# CASE SENSITIVE METHOD
<Files .htaccess>
 order allow,deny
 deny from all
</Files>

Weak pattern matching — Recently, I have been seeing several instances of this particular technique. Using the same general strategy, this method will prevent access to any file beginning with the characters “.ht”. The assumption here is that HTAccess files are the only files that begin with “.ht”. Thus, by simply matching these first three characters, all HTAccess files — and only HTAccess files — will be protected from external access. Unsafe assumptions aside, this method also relies on a case-sensitive match in order to work. Note, however, the addition of the “Satisfy All” directive in the penultimate line — this is an improvement over the previous method.

# WEAK PATTERN MATCHING
<Files ~ "^\.ht">
 Order allow,deny
 Deny from all
 Satisfy All
</Files>

Strong pattern matching — This is the method that I use here at Perishable Press. Using strong pattern matching, this technique prevents external access to any file containing “.hta”, “.HTA”, or any case-insensitive combination thereof. To illustrate, this code will prevent access through any of the following requests:

  • .htaccess
  • .HTACCESS
  • .hTaCcEsS
  • testFILE.htaccess
  • filename.HTACCESS
  • FILEROOT.hTaCcEsS

..etc., etc. Clearly, this method is highly effective at securing your site’s HTAccess files. Further, this technique also includes the fortifying “Satisfy All” directive. Note that this code should be placed in your domain’s root HTAccess file:

# STRONG HTACCESS PROTECTION
<Files ~ "^.*\.([Hh][Tt][Aa])">
 order allow,deny
 deny from all
 satisfy all
</Files>

Suggestionz

Can you improve on this technique? How do you protect your HTAccess files? Speak up!

Related articles

About this article

This is article #548, posted by Jeff Starr on Tuesday, May 20, 2008 @ 07:21am. Categorized as Function, and tagged with apache, htaccess, security, tips. Updated on May 20, 2008. Visited 11066 times. 9 Responses »

BookmarkTrackbackCommentSubscribeExplore

« CSS Hackz Series: Minimum Width, Maximum Width for Internet Explorer 6 • Up • Perishable Press HTAccess Spring Cleaning, Part 1 »


9 Responses

1 • May 20, 2008 at 7:35 pm — Sat says:

I can see how your version is superior and thanks for sharing, but don’t understand the need for “satisfy all”. According to both apache 1.3 and 2.0 docs, satisy all/any is only useful when combined with “require”, i.e.satisy user auth and deny/permit.You are far more knowledgable with .htaccess and apache than I am, so was just wondering if there is anything I’m missing with this because I didn’t see a require directive here.

2 • May 20, 2008 at 9:13 pm — Perishable says:

Yes, you are correct. I should have verified my sources before posting this article. Although I don’t think inclusion of the “satisfy all” directive does any particular harm when used in this context, it certainly isn’t “fortifying” anything either.
Thanks for keeping me honest, Sat! ;)

3 • May 21, 2008 at 6:30 am — Louis says:

Hey, I though the .htaccess were by default protected from external queries !

I wonder if it wouldn’t be easier (and less ressources eating) to CHMOD the .htaccess so that it can only be read by the server.

4 • May 21, 2008 at 4:28 pm — Perishable says:

The idea here is to protect your htaccess files on multiple fronts. Yes, on properly configured servers, htaccess files should be restricted by default, however, if someone discovers an associated vulnerability, and no additional security measures are in place, serious damage could be done. As you mention, setting an appropriate CHMOD value for htaccess files is also important, as it provides a secondary measure of protection, however, even then, if someone discovers a way around this, extensive damage could be done. Granted, these cases are merely hypothetical, however because of the inherent power involved with htaccess directives, it is important to secure htaccess files on as many levels as possible. The protective technique(s) provided in this article provide a tertiary level of defense on properly configured machines. Bottom line: it never hurts to have too much protection when it comes to htaccess. If a fourth method were available, I would use it as well.

5 • August 22, 2008 at 2:52 am — Aldo says:

Thank you very much for your blog: it was (and is) very very useful to me.

About CHMOD of htaccess, can I know what’s the best value? 644?

6 • September 1, 2008 at 9:54 am — Jeff Starr says:

Hi Aldo, Thanks for the kind words :)

As for CHMOD values, it’s always best to use the most secure settings possible. That is, if you can get away with using 644 and still maintain the desired functionality, then use it. If that is too restrictive, then try the next least permissive setting (e.g., 755), and so on. Only as a last reort (and in some cases not at all) should you enable full rights (e.g., 777) for any file or folder. Unfortunately, in many cases, that is the only thing that will work.

7 • September 1, 2008 at 11:02 am — Aldo says:

Yep, I am using 644!
Thanks for your kind reply. ;)

Drop a comment


Trackbacks / Pingbacks

  1. Sicherheit / WordPress absichern
  2. WordPress 28153-wordpress-hakkinda-birkac-soru - Zoque.Forum

Set CSS to lite theme
Set CSS to dark theme