Improve Site Security by Protecting HTAccess Files
by Jeff Starr on Tuesday, May 20, 2008 – 27 Responses
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.htaccessfilename.HTACCESSFILEROOT.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!
![[ Jeff Starr ]](http://images.monzilla.biz/serious/jeff-starr.png)
![[ Advertise Here ]](http://images.monzilla.biz/serious/adspot.png)
27 Responses
Add a comment
Sat – #1
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.
Perishable – #2
Yes, you are correct. I should have verified my sources before posting this article. Although I don’t think inclusion of the “
satisfyall” directive does any particular harm when used in this context, it certainly isn’t “fortifying” anything either.Thanks for keeping me honest, Sat! ;)
Louis – #3
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.
Perishable – #4
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
CHMODvalue 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.Aldo – #5
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?
Jeff Starr – #6
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
644and 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.Aldo – #7
Yep, I am using 644!
Thanks for your kind reply. ;)
Alex – #8
It is even safer to use 444 CHMOD code rather than 644.
Jeff Starr – #9
@Alex: indeed, that is the case if the file/folder retains its functionality with such restrictive settings applied. In my experience, some server configurations are rather picky when it comes to file permissions. My rule of thumb is to always go with the most secure settings possible, but unfortunately on my current server,
644is about as restrictive as I can go without sacrificing functionality.jidanni – #10
First of all, all the servers I’ve encountered don’t let people browse .htaccess.
Second, I don’t see how any 444 (-r–r–r–) permission or looser is considered secure in terms of not letting somebody read something.
If you want something wacky, see https://core.trac.wordpress.org/ticket/9185 where people can execute PHP left and right.
Tom Lewis – #11
Oh, wow, thats ausom, i didnt realize that you could read other peoples .htaccess files!
Thanks for the heads up!
Jeff Starr – #12
@Tom Lewis: Actually you can’t. At least not theoretically. When Apache is installed and configured correctly with the proper modules and security settings implemented, external access to per-directory HTAccess files is explicitly prohibited.
Of course, when these conditions aren’t met, or if there is a conflict with a third-party script, Frontpage extensions, or even other HTAccess directives, the protective measures for HTAccess files may not function as expected.
Such situations are hopefully rare, but the information provided in this post should cover your bases and keep your site secure should such a vulnerability present itself.
Better safe than sorry!
AskApache – #13
Haven’t been to your site in awhile, man is it looking amazing, nice work!
Couple notes:
FilesMatchshould always be used instead ofFilesfor regex according to Apache (and source).Also, the reason that by default the regex is
\.htinstead of\.htais to also protect .htpasswd files.Consider Instead
<FilesMatch "^.*(\.log|wp-config\.php|\.[hH][tT].*)$">Order allow,denyDeny from allSatisfy All</FilesMatch>Jeff Starr – #14
@AskApache: Very nice improvement — thanks for sharing :)
Also great to see you back in action (online)!
AskApache – #15
Thanks Jeff.. but I made a big mistake in that code.. Can you figure it out? Here’s the bad code:
<FilesMatch "^.*(\.log|wp-config\.php|\.[hH][tT].*)$">Order allow,denyDeny from allSatisfy All</FilesMatch>Here’s the fixed code.. The above code will deny all requests to .html files!
<FilesMatch "(\.log|wp-config\.php|\.[hH][tT][aApP].*)">Order allow,denyDeny from allSatisfy All</FilesMatch>AskApache – #16
Just remembered this little gem. It’s nice because unless the rewrite engine is off, it will always deny access, and it’s case-insensitive
RewriteRule \.ht[ap] - [NC,F]Jeff Starr – #17
Very nice! =)
Trackbacks / Pingbacks