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
/.git/config
/javascripts/.git/config/stylesheets/.git/config/images/.git/config
/CVS/Entries
/javascripts/CVS/Entries
/stylesheets/CVS/Entries
/images/CVS/Entries
- code repository URL (host, port, protocol, path)
- usernames of committers
- code repository listings of files in a directory
$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.

With regard to the git comments, unless you are using git submodules to pull in your assets, the only place a .git directory will be is at the top of the project.
Another solution is to add some commands which "clean" the public directory once the deployment is done.
In capistrano, this would be callback after 'deploy:update_code'.
(Note: this would cripple subversion from being able to function)
Cheers.
@tim: quite right, I copied and pasted the list for each SCM without thinking too much on this.
Your Apache example does not show up correctly. The part with "<directorymatch..." is missing
@sidonath: thanks. It should be fixed now!