Preventing Information Leaks, Part 3

Written on 10:44:00 AM by S. Potter

In the third part of the how to prevent information leaks blog post series, we will look for unguarded "hidden" files where we can garnish quite a bit of information. Make sure you check out part 1 and part 2 on how to prevent information leaks in web applications before continuing.

Seek Unguarded Hidden Files

For web applications that use deployment tools that pull code from code repositories, you can find out quite a bit of information about the code repository (e.g. host, path, usernames, file listings), by finding unguarded hidden files. One obvious example especially in the SVN saturated Rails world is the path /.svn/entries and similar URLs. You will want to make sure the following URIs are not accessible on your public sites if you use Subversion (SVN):

• /.svn/entries
• /javascripts/.svn/entries
• /stylesheets/.svn/entries
• /images/.svn/entries

If you are using a superior SCM for your project like Git you ought to be looking for the following:

• /.git/config
• /javascripts/.git/config
• /stylesheets/.git/config
• /images/.git/config

If your project is still in the stone-age using CVS, then check the following:

• /CVS/Entries
• /javascripts/CVS/Entries
• /stylesheets/CVS/Entries
• /images/CVS/Entries

Adapt these patterns for your application framework default structures. The above is for Rails or Rails-based frameworks (e.g. Merb). When I first tried this last week on the Rails top 10 sites, three out of ten of these sites exposed their SVN information (and last week I had only checked SVN, no Git or CVS URIs). Since last week at least one of those sites have fixed the problem! What information is exposed in these files? Quite a lot of information. Do you want potential hackers knowing:

code repository URL (host, port, protocol, path)
• usernames of committers
• code repository listings of files in a directory

All these things are not things you really want the potential hacker knowing. On my travels investigating the top 100 Rails sites I found one top 20 site that exposed enough information from their SVN entries file that I found a prototyping directory that included a "specs.rtf" document, which I was able to download. The document was not very uninteresting (at least not to me), but if they had written more in-depth specifications in the document, it may have served as a nice guide for a potential hacker to garnish enough information about their setup to take over! Moral of this story? Guard hidden files. I recommend "forbidding" access to all troublesome path regex patterns. For example, one of the LigHTTPd servers I administer has the following at the top of the configuration file:

$HTTP["url"] =~ ".*/\..*" {
  url.access-deny = ("")
}

For Apache httpd servers I use something like the following in the httpd.conf:

<DirectoryMatch "^.*\..*">
  ErrorDocument 403 /403.html
  Order allow,deny
  Deny from all
  Satisfy All
</DirectoryMatch>

Nginx configuration might look something like:

location ^~ /\..* {
  deny    all;
}

This guards against URLs like: /.svn/entries, .git/config as well as .htpasswd, etc. This means that only some script-kiddie hackers will mistakenly think you are using one SCM system instead of another, but they will never be able to know for sure which SCM you use or any information about your code repository. Forbidding access to all paths containing "/." somewhere in the URL is generally a good idea (IMHO) as sometimes people change web servers and leave "secret" files in the directory structure, but the new server doesn't know that, for example, .htaccess or .htpasswd is "special", so it will just serve it without thinking.

Posted in information leaks, rails, ruby, security

If you enjoyed this post Subscribe to our feed