Looking for a Django developer? Red Robot Studios is now accepting clients for Django development projects. Find out more...

Serving websites from svn checkout considered harmful

22 April 2008

Serving from a working copy

A simple way to update sites is to serve them from Subversion working copies. Checkout the code on the server, develop and commit changes, then svn update the server when you’re ready to release.

Security concerns

There’s a potential security problem with this. Subversion keeps track of meta-data and original versions of files by storing them in .svn directories in the working copy. If your web server allows requests that include these .svn directories, anything within them could be served to whoever requests it.

Requests would look like:

http://example.com/stuff/.svn/entries
http://example.com/stuff/.svn/text-base/page.php.svn-base
http://example.com/stuff/.svn/text-base/settings.py.svn-base

The first one would reveal some meta-data about your project, such as file paths, repository urls and usernames.

The second one may be interpreted as a PHP script, in which case there’s little risk. Or it may return the PHP source file, which is a much bigger risk.

The third one (assumed to be a Django project) should never happen. The request can only be for files within the web server’s document root. Code itself doesn’t need to be there, only media files do.

Alternatives

Instead of serving sites from a working copy, you can use svn export to get a “clean” copy of the site which does not include .svn directories. If you svn export from the repository, you must export the complete site, rather than just update the changed files, which could be a lot more data.

However, you can svn export from a working copy on the server. It’s still a complete export, but you don’t have to trouble the repository, so it’s typically much quicker.

An alternative is to update a working copy which is stored on the server, but not in the web document root, then use rsync or some file copying to update the “clean” copy in the web document root. In this case, only changed files are affected.

Protection through web server config

If you do serve from working copies, you should configure the web server to block all requests which include .svn in the url. Here’s how to do it for some popular web servers:

Apache

<LocationMatch ".*\.svn.*">
    Order allow,deny
    Deny from all
</LocationMatch>

Lighttpd

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

Nginx

Using the location directive which must appear in the context of server.

server {
location ~ \.svn { deny all; }
...
}
Filed under: Hosting, Security — Scott @ 9:48 pm

4 Comments »

  1. Wow! Thanks for opening my eyes on this.

    I’m so surprised that this isn’t a well-known issue for web developers using subversion.

    I just sent your article out to a bunch of colleagues.
    Thanks again,
    Jonathan

    Comment by Jonathan — 26 October 2008 @ 3:09 pm

  2. I use darcs rather than svn for my webpage, and noticed the darcs equivalent to this a few months ago. It’s a problem with most VC systems.

    Comment by Jason — 19 December 2008 @ 2:27 am

  3. i’ve been messing around with my lighttpd regex patterns trying to solve this issue –


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

    still allows me to access/download the /.svn/entries and /.svn/format files, but protects the directory. Anyone else have similar results?

    p.s. – i’m actually planning on using:


    url.redirect-code = 404

    instead of

    #url.access-deny = ("")

    I believe this is a better strategy – that way you’re denying that the files are even there. The equivalent in Apache is:


    RedirectMatch 404 /\\.svn(/|$)

    (the apache directive protects the entries and format files)

    Any help is appreciated!!

    Comment by rtw — 12 March 2009 @ 8:27 pm

  4. stupid russian idiots published this news 1 year after you…))

    http://habrahabr.ru/blogs/infosecurity/70330/

    Comment by Alex — 18 January 2010 @ 1:07 am

RSS feed for comments on this post. TrackBack URL

Leave a comment