Please remove that .git folder

Have you ever tried to browse http://yoursite.com/.git/?

If you get a 403 error, that's normal. It means directory browsing is disabled, which is basic security. However, many files in the .git/ folder could be accessible, putting you at risk.

.git/ folder leakage: easy exploit

N.B.: use the tool below at your own risks

WangYihang / GitHacker

🕷️ A `.git` folder exploiting tool that is able to restore the entire Git repository, including stash, common branches and common tags.

GitHacker

Desciption

This is a multiple threads tool to exploit the .git folder leakage vulnerability. It is able to download the target .git folder almost completely. This tool also works when the DirectoryListings feature is disabled by brute forcing common .git folder files.

With GitHacker's help, you can view the developer's commit history, branches, ..., stashes, which makes a better understanding of the target repo, even to find security vulnerabilities.

PROCLAMATION (IMPORTANT)

Several VULNERABILITIES have been reported recently, if you are using GitHacker <= 1.1.0, please update your tool as soon as possible.

The remote .git folder maybe malicious, so to prevent you from being attacked. It's highly recommended that you SHOULD run this tool under a disposable jailed environment (eg: Docker container).

Requirments

• git >= 2.11.0
• Python 3

Usage in Docker (Recommended)

# print help info
docker run wangyihang/githacker --help
# quick start
docker run -v $(pwd)

…

View on GitHub

Anyone can use automated scripts such as the above repository to download your source code and view the entire git history. Git is also a filesystem that follows some conventions, so you can guess directories and files easily.

Most projects use master or main as master branch, so it's easy to guess "hidden" paths in the /.git/ folder. Note that the tool can even brute force branches and tags if that's necessary.

If the scan succeeds, you get a result folder on your local machine (you can customize the folder name with the --output-dir option).

A typical result is the equivalent of git checkout master for free!

Don't deploy the .git/ folder or, at least, forbid access

The .git/ folder can contain lots of information, including the source code itself but also names, mails, and, in the worst-case scenario, hard coded credentials (e.g. databases, tokens, keys).

For a hacker, it's like Christmas!

You should completely disable public access to such folder. Modern CI/CD and deployment solutions are relatively easy to configure and allow cleaning such directories that have nothing to do with the production environment.

Note that some web hosting providers disable access to the folder for security purpose, but it's not always the case and it's not the default configuration, so check it before deploying anything.

I recommend doing all hardenings available. While it might seem a bit overkill, it's often a good idea to take into account any misconfiguration that could occur in the future or a miscalculated migration, so:

1. Disable public access in the .git/ folder by default on your server
2. Add a rule to forbid access to the folder in your source code, for example, in the .htaccess file for Apache configurations
3. Don't even deploy such folder in public directories if that's possible

If you don't want to touch sensitive files such as the .htaccess, you can add a smaller .htaccess at the root of the .git/ folder on your server with just the following line inside:

Deny from all

However, it's even better to return a 404 for the .git/ folder in your server config or main .htaccess, so hackers won't be able to guess anything:

RedirectMatch 404 /\.git

Again, I recommend adding both rules if you can, as two layers of security. In case someone modifies the main .htaccess and delete the rule accidentally, there's still a fallback in the .git/ folder.

When migrating from one server to another, misconfigurations and oversights do happen.

Comments

[Corentin Bettiol]

Here's my config on my website:

<VirtualHost *:443>

        ServerName ***
        Serveralias ***

        ServerAdmin ***
        DocumentRoot /var/***/***/***/***

        Options FollowSymLinks MultiViews

        ErrorDocument 404 /***/404
        RedirectMatch 404 /\.git  # <-- THIS LINE HERE

        [...]

And it works well :)

[Corentin Bettiol]

(I use it in my sites-enabled/ folder because adding .htaccess files are slowing down apache and my server is not very powerful :P)

You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance.
httpd.apache.org/docs/2.4/howto/ht...
​
The httpd.conf is parsed one time. If you use .htaccess it'll get hit every time something is called. That'll cause a fairly large performance hit that will just get worse with increasing requests.
stackoverflow.com/a/25064109/6813732

[pO0q 🦄]

hello, the good news is you can manage it wherever you want, but do you have any figures or test results for the performances? I'd be curious to know why .htaccess would slow down the entire architecture, especially your number of hits.

[Corentin Bettiol]

I haven't done any test on my server, but I will quote another SO answer:

Also, when [.htaccess is] enabled the server will take a potential performance hit. The reason is because, every server request, if .htaccess support is enabled, when Apache goes to fetch the requested file for the client, it has to look for a .htaccess file in every single directory leading up to wherever the file is stored.
stackoverflow.com/a/29114826/6813732

[Matthijs Wensveen]

My advice would be to never have the website root at the project root. Always use a www, html, public, or even src subdirectory. This way, the .git directory and files like README.md are not exposed to the internet.

If you deploy by using git pull on the server and your hosting provider only provides a webroot, this article has good advice. 👍

[pO0q 🦄]

Totally on point: no public access! I wrote this post for those who do not have that in mind. In fact, even if you are on a budget, you don't have to deploy such folder. It's just more convenient for many people, but not mandatory. There are other ways to sync you code.

The problem with cybersecurity is you don't always have the best conditions, so many people will tell you "don't put anything sensitive in git, etc," which it's true in a perfect world, but sometimes more difficult to achieve in reality.

I prefer having several layers, and if I can remove that .git folder from public folder, I'll do it :)

[Matthijs Wensveen]

Absolutely! Sometimes hosting providers don't give a lot of options on how or where to deploy. Or maybe someone isn't even aware that this is problematic.

Maybe a web.config equivalent of this article would be useful as well, for those who use IIS.

[Dendi Handian]

this is a kind of fear that would happened if I build a code from scratch by myself without understanding web security. for the security, I always rely on frameworks.

[Petrus-Nauyoma]

I totally get you. Imagine leaking api keys in the env folder. Frameworks really help to get on your feet a bit quicker. Otherwise all these little but disastrous security details are hard to come by especially without a patient senior mentor/dev.

[Vincent Milum Jr]

A better strategy: don't put sensitive credentials in your git repos to begin with.

The .htaccess recommendation is limited in what servers even support that directive. There are methods to do it with others, but this becomes a separate security nightmare of making sure infrastructure never changes over time (which is within itself a different bad practice)

Security credentials should be stored using a dedicated secrets manager outside of the repo. This is especially true because dev/staging/test/prod/etc should all have separate credentials ANYWAYS, so mish-mashing them all together in the repo with conditions isn't best practices to begin with.

[ytjchan]

Some info can be stored in .git folder such as commit user name and email using git config, which defaults to storing them into .git/config.

[Phil Ashby]

Good layered defence approach! I would also advocate for automating deployment to always use a safe export mechanism (eg: git archive) that omits the internals of the source control.

For cloud-hosted deployments, your provider of choice will likely have an arsenal of tools to help deploy stuff (typically workflow pipelines, secret management, versioning, auto-rollbacks, ...).

[pO0q 🦄]

Indeed. Nice suggestion.

It's true that providers offer an extensive range of configurations and tools to automate deployments, but it's kinda the same problem if you misuse them or misconfigure security settings.

Besides, if hackers manage to steal access to those interfaces, which happens a lot, it's game over too.

In a nutshell, I agree with you on automation but admins should be careful with their credentials and ensure they understand how the cloud-based system works.

[Sean Cassiere]

It's funny, because I've been using cloud providers for deploying my frontends, with the backends requiring me to allow folders to be publicly accessible, and therefore haven't dealt with/or even though about this aspect of security before.

Could definitely see this affecting beginners and students, that use static plain HTML or PHP websites deployed.

[pO0q 🦄]

Yes, it's easy to git pull your project and forget that :(

[slidenerd]

Some whitehat hacker reading this should run a brute force bot to traverse every website out there and make a list of the ones that did hit the .git folder, extract their admin emails and send them an automated message or at the easiest make a list of them similar to haveibeenpwned.com i think

[pO0q 🦄]

yeah, people always forget that, in git data, hackers do not look for hard coded keys or database credentials only, there are so many valuable information you can get...

Unfortunately, while your suggestion could make sense, it's hard to determine whether you have a white or a grey hat approach here (I would say grey). If the website does not include any security.txt or does not explicitly invite white hackers to test the website (e.g. bug bounty) and contact them, it might be considered illegal in many countries.

[mikcat]

I'm used to add this to the main apache config:

<DirectoryMatch "/\.git">
   Require all denied
</DirectoryMatch>

[pO0q 🦄]

EDIT: your example is better than mine.

[Kelvin Clark]

Wow this is very informative.

[Fongoh Martin T.]

Thank you

[Ricardo Chan]

Great tip!

[Randell Brian Knight]

Thanks for sharing this excellent git security information and hardening tips.

[Pandademic]

Lovely article!

[Jing Xue]

If your .git gets deployed, your DevOps engineer ought to be fired.

It's as simple as this: "do not deploy .git".

All this access blocking business is pointing in the wrong direction.

[pO0q 🦄]

Security is not "as simple as this." When the damage is done, firing people is just a consequence, not a solution. Besides, if you read the post, you'll see it explicitly says "don't deploy git". Blocking is just an additional layer of protection for those who don't have that knowledge, the possibility to change configurations, or DevOps to fire.

[Jing Xue]

Lol. Looks like my comment was hidden too.

The point is that .git should not be deployed whatsoever, which should have been easily verifiable in a lower environment before it gets into production, so there should not be a scenario where you have to scramble to block access to it.

[Jing Xue]

Lol, you mention "don't deploy the .git/ folder" once, and spend literally the rest of the post talking about blocking access to a deployed .git folder. The impression you are making is that having .git deployed is an acceptable scenario, and the solution is to control access. My point is exactly that having .git deployed to a production server is not acceptable under no circumstances, and that there ought not be any scenario where this even accidentally happens, because any proper CI process should catch it.