Protect .git, .hg and .bzr directories in .htaccess

Is it worth also expanding this for hg, bzr and any other common version control systems? Otherwise we will end up with a plethora of issues for these.

Seems like a very good idea.

based on #3

Maybe this should just be generalized to all directories prefixed by a dot?

Tested and works as expected. Bumping priority as this will effect lots of people.

Hm. Is there a more generic way to handle this? Like excluding all files/directories that begin with a "."? This looks pretty dirty, and we'll need to keep maintaining it over time.

Also, critical is for "Drupal is actively dripping blood from its eyeballs." This doesn't remotely qualify. I don't think there's anything in these files that exposes anything security-wise, and even if so, people smart enough to use bzr/git/etc. can figure out their own re-write rules.

Can confirm that this patch protects my .git directory which i deliberately placed in the webroot (big no-no under previous circumstances) when mod_rewrite is on. Same should be true for .hg, .svn, and .bzr since it's a generic rule protecting all directories beginning with a dot.
Files beginning with a dot are effectively protected by the FilesMatch directive.

Marking RTBC.

sorry, RTBC'd too early, since I just read that two people have to sign off on a patch before RTBC-ing. Patch really works though :-)

RTBC.

+++ .htaccess	15 Jan 2010 22:08:34 -0000
@@ -56,18 +56,32 @@ DirectoryIndex index.php index.html inde
+  # ¶
+  # If you do not have mod_rewrite installed, you should remove these
+  # directories from your webroot or otherwise protect them from being
+  # downloaded.
+  RewriteRule "(^|/)\." - [F] ¶

2 minor whitespaces issues

Great! Much better. :) Fixed up some of the language there (spell out 'version control system', add a missing word) and committed to HEAD.

Here's the patch I committed. Marking down for 6.x. Doesn't seem to apply cleanly, though.

while at VCS, would .orig/.rej files worth be protected as well?

We can discuss that in a separate issue, but I kind of don't think so. It's one thing to protect against legitimate files that might be there if using certain deployment practices, but quite another to babysit people.

Rerolled patch

Committed fix Feb 7: #581706 by c960657: Protect hidden directories (.git, .svn, etc.) in .htaccess.

This has not been committed to Drupal 6.x.

Maybe this should just be generalized to all directories prefixed by a dot?

Because of this generalization i have some pages on my site blocked. Their names is started with dot, so i have 403 Forbidden on them. I figured out, that rule RewriteRule "(^|/)\." - [F] is wrong, because it have to check whether name is file/directory name or should be passed to drupal.

But anyway, I still dont know what to do with line

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\.*|Entries.*|Repository|Root|Tag|Template)$">

I think it will be more preferable write out every expected dot-whatever directory rather than simply ".*" like

<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\.git.*|\.hg.*|\.bzr.*|\.svn.*|\.cvs.*|Entries.*|Repository|Root|Tag|Template)$">

it's includes files like .gitignore, so i think everything is under control :)

p.s. i'm using drupal 7, but as i can understand it's common bug, so i didn't start new issue for 7.0. Is it ok?

I was wondering if blocking all things starting with a dot was too general also.

Blocking all things starting with a dot is definitely too general, because:

• It's perfectly valid to create a menu path, say in a view, that starts with a dot.
• When the user does this and tries to access the URL, Apache puts up its Access Denied page. Drupal's code is never even called. This makes it VERY difficult for the user to figure out why their perfectly valid menu path fails.

I agree with the part of #28 which uses tests of "-f" and "-d" to ensure the thing being blocked exists in the filesystem first:

  RewriteCond %{REQUEST_FILENAME} -f
  RewriteRule "(^|/)\." - [F]
  RewriteCond %{REQUEST_FILENAME} -d
  RewriteRule "(^|/)\." - [F]

I am changing the version of this issue to 7.10, because the change is already live in D7, not in D6. The attached patch is for D7.

[Edit: I am withdrawing my patch. I incorrectly left out the modification to the long FilesMatch clause, and my patch would therefore not solve the problem. I now believe that the solution in #28 is the best course. It also applies cleanly to D8. I am resubmitting it for consideration with D8.]

Bugs are fixed in D8 then backported.

#28: vcs-htaccess-7.patch queued for re-testing.

Leading .DOT in path should be working and let modules to use it. eg: #1661098: Autocomplete and words beginning with dot (.)

Attached a patch and tested:
- It blocked .git, .anything
- It allow example.com/.abc

Hunh. Stepping back for a moment, instead of blocking requests for individual files, it likely makes more security sense for us to create a whitelist of acceptable requests of Drupal; everything else would be ignored. That's because we can never cover all the bases in our FilesMatch rule (essentially our blacklist) of the files that an individual user, installing Drupal and then setting to work on their site, might leave littered around. We will always be playing catch-up.

It's true that creating and maintaining a whitelist is harder, since we have to overcome some habits: both Drupal core and contrib modules right now can arbitrarily create files, and will expect them to be delivered properly by the Web server software.

However we would have fewer habits to overcome, if modules could update this HTTP request whitelist upon creating a file.

Another option is user education, making sure that users know that any files placed in Drupal's docroot may be delivered by their Web server in response to any legitimate request.

@forestmonster: thanks for bringing a fresh perspective to this.

Whitelisting is generally a better security practice and given that it is also not proper use to just drop files in the drupal root (although I know people commonly do so) this seems like a logical direction to take. People can always whitelist there odd files if they really want to.

This will probably end the nasty "OMG, anyone can see Drupal's version by checking the CHANGELOG.txt security dripping blood from its eyes omg omg". As if we couldn't tell an opensource framework version by its CSS/JS.

Anyway, to get this rolling, we should whitelist:

* index.php
* core/install.php
* core/update.php
* sites/*/files/* (files, not dirs)
* robots.txt
* themes/modules css/js/img (other media?)

Not sure how the redirect works with whitelisting since you can hit /install.php and it works fine. core/authorize.php?

And a related discussion is going on at #1907704: Restrict temporary files created by text editors.

Added #1907934: Allowlist, instead of denylist, sensitive files and directories to handle these sorts of requests.

If you're going to whitelist sites/*/files/*, what happens when someone uses the UI to change where files are stored?

Drupal should support RFC 5785, which establishes a .well-known URI location: https://tools.ietf.org/html/rfc5785

These URIs are registered with IANA - https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml - and include for example .well-known/openid-configuration as described at http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig

So either .well-known needs to be whitelisted, or only specific hidden directories (.bzr .git .hg .svn etc.) should be blacklisted.

Updated patch at #34 to whitelist the .well-known path.

I can't believe this has been sitting here like his since july 2012.
Droplets "tested" patch:

  RewriteCond %{REQUEST_FILENAME} -f
  RewriteCond %{REQUEST_FILENAME} -d
  RewriteRule "(^|/)\." - [F]

This is checking if the requested path is both a file AND a directory at the same time and thus will never block anything.

OK I added the [OR] flag to fix that..

45: htaccess.patch queued for re-testing.

rerolled

I'd really like to add support for the .well-known directory to D7 so I created #2408321: Support RFC 5785 by whitelisting the .well-known directory in hopes of getting this part of the patch in faster.

Using Drupal 8.0.x I tried to access http://localhost:8888/.git and .hg and .bzr.

In all cases I got something this:

Forbidden

You don't have permission to access /.git on this server.

So therefore I'm calling this issue CWF. Please re-open if this is in error.

There's also some overlap with #2408321: Support RFC 5785 by whitelisting the .well-known directory