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)…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:
- Disable public access in the
.git/folder by default on your server - Add a rule to forbid access to the folder in your source code, for example, in the
.htaccessfile for Apache configurations - 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.
Top comments (42)
Here's my config on my website:
And it works well :)
(I use it in my
sites-enabled/folder because adding.htaccessfiles are slowing down apache and my server is not very powerful :P)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
.htaccesswould slow down the entire architecture, especially your number of hits.I haven't done any test on my server, but I will quote another SO answer:
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. 👍
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 :)
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.
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.
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.
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.
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.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, ...).
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.
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
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.txtor 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.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.
Yes, it's easy to
git pullyour project and forget that :(I'm used to add this to the main apache config:
EDIT: your example is better than mine.
Wow this is very informative.
Lovely article!
Some comments have been hidden by the post's author - find out more