Ignoring .svn directories under IIS

Question

We are a web development organization and have recently moved to using subversion for our version control system. Since executing an update is so much faster than doing an export and copying over the files, the developers want to be able to have the production server be a working copy.

The only concern I have with this is all of the .svn files littered across the system, and the fact that some enterprisey individual could, potentially, read the contents of the files in there, possibly giving them information we would rather they did not have.

What is the best/easiest way to prevent IIS from serving up any content from within those .svn directories?

Answer 1

"Don't do it that way" does not answer the question.

Practically, I like having a working copy on the production server, because that way I can make quick changes in production (who has never done that?) and check them back in. It depends on where you want your security/convenience slider, and in many cases this is a good place.

The standard solution in Apacheland is to leave the .svn files there but tell the web server to never serve them. Here's how to do that with IIS 5-7 on Windows 2000-2008.

1. Download and install ISAPI_Rewrite -- the Lite version will be enough for this purpose. Note extra system requirements for Win 2008. Warning-- the MSI installer stops and starts IIS.

2. Uncheck the "read only" box on the httpd.ini file's properties. If you used the MSI installer, therer's a shortcut to the httpd.ini file in the Start menu under Helicon->ISAPI_Rewrite

3. Add these lines to httpd.ini:

ISAPI_Rewrite directives in httpd.ini:

# Deny access to Subversion working copy administrative
#  directories (.svn) and their contents
RewriteRule .*/\.svn\b.* . [F,I,O]

Now, any request for a .svn directory or its contents will result in a 404 Not Found from the server.

Answer 2

You could make sure that any user accounts used by IIS do not have rights to access the .svn directories.

You can either do this manually (not recommended) or use something like MrJangles delete script either triggered to run after you do the SVN update or run regularly as a scheduled task:

for /r YOURPATH %f in (.svn) do icacls /deny <name_of_iis_user>:F "%f"

(note: I've not tested the above, you'll need to check it does what it is trying to before relying on it in production, see the output of "icacls /help" for more info)

(another note: "icacls" is a Vista/2008 command, on earlier Windows variants the command is "cacls" instead)

Answer 3

Using IIS 7, open IIS Manager, select the server node, double click the Handler Mappings feature. Click the action Add Managed Handler and configure the handler as follows:

• Request path: *.svn/* (wildcard mapping for all files in all .svn folders)
• Type: System.Web.HttpForbiddenHandler
• Name: Subversion-metadata (you can choose a different name if you like)

Now any request for files in the Subversion metadata folders named .svn in alle sites should return this:

Server Error in '/' Application.

This type of page is not served.

Description: The type of page you have requested is not served because it has been explicitly forbidden. Please review the URL below and make sure that it is spelled correctly.

Requested URL: /.svn/text-base/Default.aspx.svn-base

You can choose a different handler type if you want, maybe a FileNotFound handler which will return a 404 status code.

For IIS 6 (with ASP.NET 2 installed and configured):

Navigate to Home directory > Configuration > Mapping and map the .svn-base extension to %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll. Then in machine.config (which you can find in %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\CONFIG) you can add the same handler as above for the extension, add the following XML-element as a child of the <httpHandlers>-element:

<add verb="*" path="*.svn-base" type="System.Web.HttpForbiddenHandler"/>

This will only prevent visitors from requesting the source code files, they could still request other files from the .svn folders. Map more extensions to aspnet_isapi.dll or make a wildcard mapping (will impact performance) and you could block more files from being requested.

Answer 4

From a pure security standpoint, I'd re-educate your developers.

Ease of deployment is not necessarily a good idea if you sacrifice security.

You're planning a configuration to block access to sensitive information. What happens if the configuration accidentally changes. What happens if an IIS hotFix comes down and changes how your config works. What happens if the 3rd party library you use faults out and stops working. I can think of several extremely likely events that would break your config and allow access to these files, which would be TOTALLY MITIGATED by not having the files on the server in the first place.

You should create a deployment script that copies the appropriate files from a staging server. You could even stage via SVN to a different directory on Prod.

To deploy, you can use RoboCopy and the /XD command to exclude .svn directories. You can use the Microsoft web deployment tool and limit the directories with that. You can deploy and run the above for /r YOURPATH %f in (.svn) do rd /s /q "%f" if you need too.

Just don't deploy these directories to production web site.

Answer 5

Don't use subversion. Seriously.

From your comments it appears that you are using the wrong tool for the job. Subversion is a great tool for your developers, but it's not a deployment/mirroring tool. If your goal is to simply copy files from your staging/test server to your production server with a minimum of bandwidth and time, then I suggest you use rsync. Now, since I'm a Unix admin, there may be some Windows equivalent to rsync that I don't know about, so you may want to do some research. However, you can use rsync under Cygwin or cwrsync.

Rsync allows you to mirror directories on one server with directories on another. It calculates a delta between the two servers and only copies the differences. Not only that, but it compresses the delta and, optionally, can encrypt it too.

Answer 6

Best practice would be an automatic deployment system that exports and publishes after a SVN update is made. Consider Hudson for example. There are few more, but as we do not need one, I'm not very well informed

Greetz, GHad

Answer 7

I schedule a script on my production servers that searches for .svn and simply deletes the files. I don't think this will work in your case.

for /r YOURPATH %f in (.svn) do rd /s /q "%f"

If removing the files isn't an option, you could put basic security on the directories through IIS (password, or IP restrictions). This would stop IIS from serving content to unauthorized users.

Good luck!