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.

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

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:

when HTTP_REQUEST { 
    # Check the requested URI
    switch -glob [string tolower [HTTP::path]] { 
       "/.ht*" { 
             reject
          } 
       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.

Related blogs & articles:

• An Unhackable Server is Still Vulnerable
• Twittergate Reveals E-Mail is Bigger Security Risk than Twitter
• Automatically Removing Cookies
• Clickjacking Protection Using X-FRAME-OPTIONS Available for Firefox
• Stop brute force listing of HTTP OPTIONS with network-side scripting
• Jedi Mind Tricks: HTTP Request Smuggling
• I am in your HTTP headers, attacking your application
• Understanding network-side scripting