A few times recently we have run across Git repositories on live web servers. I’m not sure if this is just because GIT is becoming much more heavily used, or whether part of it is down to the recent change in development methodologies towards something more fast and fluid, but unless you are intending your code to be open source, putting copies of it on publically accessible servers is not a good plan.
The web vulnerability scanner Nikto finds these repositories with no problem. This means that unskilled attackers can also find them, with the general implication that this type of data exposure will attract untargeted attacks – ones looking for any .git repository rather than yours specifically. Repositories may be freely accessible in a web browser (and may in fact also display their entire directory structure), but even if the data doesn’t seem accessible, or even comprehensible – it is often still easily possible to extract a full copy of the source code from them.
The very comprehensive instructions on how to do this are here – https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/ and the actual tools are available here https://github.com/internetwache/GitTools. I’ve run these on quite a few occasions now, and whilst sometimes the repository is just empty, in a lot of cases the end result is a large number of dumped subdirectories with long GUID style names. Each one of these essentially contains a snapshot of the full code at the point a commit was made. So once an attacker has these, the directory structure can be grepped for interesting information like stored passwords, private keys etc. Having the supporting code is also very helpful to a attacker/tester when trying to find issues like SQLI and XSS as he can look at exactly what the developer is doing to defend against it.
So don’t store source control on production web servers, or if this is absolutely necessary, ensure that access to the repository is strictly controlled.