You are hereSide-effects of using SVN/CVS with your website

Side-effects of using SVN/CVS with your website


By chri - Posted on 18 November 2007

While reading security papers I realize we did something very stupid with the FOSDEM webserver configuration.
Like many websites we use a versioning system (CVS/SVN) to keep track of the changes and to synchronize between our sandbox-website and our public website. But something I totally forgot was one of the side-effects of doing this.

Subversion and CVS both create their hidden .svn or .cvs directories. Subversion uses the information in .svn to keep track of things like:

  • Which repository location(s) are represented by the files and subdirectories in the working copy directory.
  • What revision of each of those files and directories are currently present in the working copy.
  • Any user-defined properties that might be attached to those files and directories.
  • Pristine (un-edited) copies of the working copy files.

For more information about this .svn directory the documentation is a good place.

So what's the problem?

What's exactly in that directory?

chri@sophos:/home/services/www/fosdem.org/.svn$ ls -aR
.:
.  ..  empty-file  entries  format  prop-base  props  README.txt  text-base  tmp  wcprops
./prop-base:
.                       .htaccess.svn-base          install.php.svn-base      .project.svn-base     xmlrpc.php.svn-base
..                      index.php.svn-base          INSTALL.txt.svn-base      robots.txt.svn-base
CHANGELOG.txt.svn-base  INSTALL.mysql.txt.svn-base  LICENSE.txt.svn-base      update.php.svn-base
cron.php.svn-base       INSTALL.pgsql.txt.svn-base  MAINTAINERS.txt.svn-base  UPGRADE.txt.svn-base
...some more...
./tmp:
.  ..  prop-base  props  text-base  wcprops
...still more...

That's scary!! What happens if I enter the exact path of one of these files? Let's say: http://fosdem.org/2008/.svn/entries

<?xml version="1.0" encoding="utf-8"?>
<wc-entries
   xmlns="svn:">
<entry
   committed-rev="288"
   name=""
   committed-date="2007-10-18T05:14:28.629800Z"
   url="file:///XXXX/svn/site/trunk/drupal5"
   last-author="loki"
   kind="dir"
   uuid="e968193e-8020-0410-a39f-a17aa7e0140e"
   repos="file:///XXXX/svn/site"
   revision="288"/>
<entry
   name="profiles"
   kind="dir"/>
...and much more...

If you are creative, and understand what can be in these directories you will understand the danger of publishing it.

How do I prevent this?

A few solutions exist, it all depends on your creativity and the tools you want to use. The easiest solution is to stop using versioning on your website. But that's probably not something you like ;-).

As we run mod_security on the FOSDEM server I quickly added the following rule: SecFilter "\.svn/". This way the user gets an 406 error message.

Another solution would be to configure apache to prevent showing .svn files and directories, just what happens with the .htaccess files. You can do this like this:

<DirectoryMatch "\.svn">
Deny from all
</DirectoryMatch>

You can check by yourself: http://fosdem.org/2008/.svn/entries


Oh, btw if you want to harden your Apache webserver the following document is a good start: http://httpd.apache.org/docs/2.2/misc/security_tips.html


So true... The 'deny from all' .htaccess is a solution, but it doesn't solve the root cause. It's better to store the real repository checkout in a private location, and publish to /var/www/ using 'svn export'. Export is just like a copy, but without the SVN metadata. You can automate this with a hook script if it's too much manual work.
The Tip:
<DirectoryMatch "\.svn">
Deny from all
</DirectoryMatch>
Does not work, the directory gets blocked, but the files are still accessible directly via: .svn/entries