September 25, 2009

Potential SVN Security Risk

Smashing Magazine recently called out a potential security risk with SVN that I think is worth reposting here. This isn't an SVN vulnerability that needs a patch, but rather a symptom of poor deployment practices that are easily avoided. Here's how:

The problem is with exposing the .svn directories to the public through a Web browser. Without proper access security in place, a prying user might be able to obtain your entire site's source code which may contain sensitive information.

There are three common ways to avoid this.

1. Use 'SVN export' instead of 'SVN update' (or checkout) when deploying your code to a production site
This is the safest method as it avoids putting the .svn directories in your web directory in the first place. No .svn directories means no risk. You do however lose many of the benefits of SVN.

For example, if you have a release that deletes files, 'svn export' will not delete anything if run on an existing build, it will only overwrite existing files. In an SVN working copy, 'svn update' will automatically add and delete files in one command.

This method will work fine if you have scheduled releases and can afford to rebuild the entire site directory with every release.

2. Use rsynch to copy your files
Another safe option is to use rsynch to copy all of your files from an SVN working copy to the actual web directory ignoring all the .svn directories. You can use the following option with your rsynch command to do this:
--exclude=.svn

3. Set up your Web server to deny access to your .svn directories
This is simple and just as effective. The Smashing Magazine post gives solid examples to achieve this with Apache.

All three options are safe. Options 1 and 2 pose no risk of exposure with no extra configuration while option 3 requires some minor Web server tweaking. I personally like option 2. It gives you the best of both worlds: no risk and all the great benefits of controlling your code with SVN.

Posted at 07:31 pm by DPCI Bloggers

Add comment

• A Crisis of Identity in the Digital Age 01/14/2010 - 21:30
• Presentation on Scaling Drupal in the Enterprise 11/05/2009 - 11:33
• Messenger's Error(s): Chris Wilson's flawed rant about Drupal and whitehouse.gov 10/27/2009 - 20:54
• Automating Drupal Site Rebuilds With Drush 10/05/2009 - 12:38
• A Look at the Drupal Features Module 09/29/2009 - 22:15
• What TweenBots Can Teach About Federating Tasks 05/26/2009 - 18:53
• Using Drupal Module Install Scripts to Simplify Site Deployments 04/03/2009 - 11:35
• Drupal Usability 03/26/2009 - 15:17
• Drupal vs. Joomla! 03/03/2009 - 09:32
• A New Era: Artists' Digital Rights Get Organized 02/25/2009 - 22:08