I Can Has UR .htaccess File

Notice that isn’t a question, it’s a statement of fact

Twitter is having a bad month. After it was blamed, albeit incorrectly, for a breach leading to the disclosure of both personal and corporate information via Google’s GMail and Apps, its apparent willingness to allow anyone and everyone access to a .htaccess file ostensibly protecting search.twitter.com made the rounds via, ironically, Twitter.

This vulnerability at first glance appears fairly innocuous, until you realize just how much information can be placed in an .htaccess file that could have been exposed by this technical configuration faux pas.

Included in the .htaccess file is a number of URI rewrites, which give an interesting  view of the underlying file system hierarchy Twitter is using, as well as a (rather) lengthy list of IP addresses denied access. All in all, not that exciting, because many of the juicy bits that could be configured via .htaccess for any given website are not done so in this easily accessible .htaccess file.


Some things you can do with .htaccess, in case you aren’t familiar:

  • Create default error document
  • Enable SSI via htaccess
  • Deny users by IP
  • Change your default directory page
  • Redirects
  • Prevent hotlinking of your images
  • Prevent directory listing

.htaccess is a very versatile little file, capable of handling all sorts of security and application delivery tasks. Now what’s interesting is that the .htaccess file is in the root directory and should not be accessible. Apache configuration files are fairly straight forward, and there are plethora examples of how to prevent .htaccess – and its wealth of information – from being viewed by clients. Obfuscation, of course, is one possibility, as Apache’s httpd.conf allows you to specify the name of the access file with a simple directive:

AccessFileName .htaccess

It is a simple enough thing to change the name of the file, thus making it more difficult for automated scans to discover vulnerable access files and retrieve them. A little addition to the httpd.conf regarding the accessibility of such files, too, will prevent curious folks from poking at .htaccess and retrieving them with ease. After all, there is no reason for an access file to be viewed by a client; it’s a server-side security configuration mechanism, meant only for the web server, and should not be exposed given the potential for leaking a lot of information that could lead to a more serious breach in security.

 ~ "^\.ht">    Order allow,deny    Deny from all    Satisfy All

Another option, if you have an intermediary enabled with network-side scripting, is to prevent access to any .htaccess file across your entire infrastructure. Changes to httpd.conf must be done on every server, so if you have a lot of servers to manage and protect it’s quite possible you’d miss one due to the sheer volume of servers to slog through. Using a network-side scripting solution eliminates that possibility because it’s one change that can immediately affect all servers.

Here’s an example using an iRule, but you should also be able to use mod_rewrite to accomplish the same thing if you’re using an Apache-based proxy:

    # Check the requested URI
    switch -glob [string tolower [HTTP::path]] { 
       "/.ht*" { 
       default {  
          pool bigwebpool 



However you choose to protect that .htaccess file, just do it. This isn’t rocket science, it’s a straight-up simple configuration error that could potentially lead to more serious breaches in security – especially if your .htaccess file contains more sensitive (and informative) information.


AddThis Feed Button Bookmark and Share

Published Jul 21, 2009
Version 1.0

Was this article helpful?


  • @Roch



    I don't think that .htaccess itself can scan the payload, which you'd need to do on either the submit or the response to find offensive URIs and either strip them out or replace them.



    However, you can use .htaccess to block access from YOURDOMAIN.com in general. Check out this article on blocking referrer spam and this one as well





  • Dan_Griffin_16's avatar
    Historic F5 Account
    Agree with @fak3r. Everthing that can be done with .htaccess can be done in the main apache config file or a virtual host config file, so when you have full control of the server .htaccess should not be used.
  • @fak3r



    Good point about the shared hosting, I hadn't considered that.



    And I absolutely agree with the sentiment that some of the ways in which .htaccess is used is better off handled by an intermediary/other solution. URI rewriting? Why is that being done in .htaccess? Not. Relevant.



    Good stuff, thanks for offering it up!


  • @mike



    Or accidentally. Either way, it shouldn't be accessible and if there's a reason it should be to *specific* clients then it needs to be restricted to just those clients.