<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Flapping Head &#187; Security</title>
	<atom:link href="http://scottbarnham.com/blog/category/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://scottbarnham.com/blog</link>
	<description>Code and comments on web development, Django, Python and things (un)related.</description>
	<lastBuildDate>Thu, 08 Jul 2010 09:49:01 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Serving websites from svn checkout considered harmful</title>
		<link>http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/</link>
		<comments>http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/#comments</comments>
		<pubDate>Tue, 22 Apr 2008 20:48:28 +0000</pubDate>
		<dc:creator>Scott</dc:creator>
				<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/</guid>
		<description><![CDATA[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&#8217;re ready to release.
Security concerns
There&#8217;s a potential security problem with this.  Subversion keeps track of meta-data and original versions [...]]]></description>
			<content:encoded><![CDATA[<h3>Serving from a working copy</h3>
<p>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 <code>svn update</code> the server when you&#8217;re ready to release.</p>
<h3>Security concerns</h3>
<p>There&#8217;s a potential security problem with this.  Subversion keeps track of meta-data and original versions of files by storing them in <code>.svn</code> directories in the working copy.  If your web server allows requests that include these <code>.svn</code> directories, anything within them could be served to whoever requests it.</p>
<p>Requests would look like:</p>
<p><code>http://example.com/stuff/.svn/entries</code><br />
<code>http://example.com/stuff/.svn/text-base/page.php.svn-base</code><br />
<code>http://example.com/stuff/.svn/text-base/settings.py.svn-base</code></p>
<p>The first one would reveal some meta-data about your project, such as file paths, repository urls and usernames.</p>
<p>The second one may be interpreted as a PHP script, in which case there&#8217;s little risk.  Or it may return the PHP source file, which is a much bigger risk.</p>
<p>The third one (assumed to be a Django project) should never happen.  The request can only be for files within the web server&#8217;s document root.  Code itself doesn&#8217;t need to be there, only media files do.</p>
<h3>Alternatives</h3>
<p>Instead of serving sites from a working copy, you can use <code>svn export</code> to get a &#8220;clean&#8221; copy of the site which does not include <code>.svn</code> directories.  If you <code>svn export</code> from the repository, you must export the complete site, rather than just update the changed files, which could be a lot more data.</p>
<p>However, you can <code>svn export</code> from a working copy on the server.  It&#8217;s still a complete export, but you don&#8217;t have to trouble the repository, so it&#8217;s typically much quicker.</p>
<p>An alternative is to update a working copy which is stored on the server, but not in the web document root, then use <code>rsync</code> or some file copying to update the &#8220;clean&#8221; copy in the web document root.  In this case, only changed files are affected.</p>
<h3>Protection through web server config</h3>
<p>If you do serve from working copies, you should configure the web server to block all requests which include <code>.svn</code> in the url.  Here&#8217;s how to do it for some popular web servers:</p>
<h4>Apache</h4>
<pre>&lt;LocationMatch ".*\.svn.*"&gt;
    Order allow,deny
    Deny from all
&lt;/LocationMatch&gt;</pre>
<h4>Lighttpd</h4>
<pre>
$HTTP["url"] =~ ".*\.svn.*" {
  url.access-deny = ("")
}</pre>
<h4>Nginx</h4>
<p>Using the <code>location</code> directive which must appear in the context of <code>server</code>.</p>
<pre>server {<br />
    location ~ \.svn { deny all; }<br />
...<br />
}</per>
]]></content:encoded>
			<wfw:commentRss>http://scottbarnham.com/blog/2008/04/22/serving-websites-from-svn-checkout-considered-harmful/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.200 seconds -->
