修复Git源码泄漏的问题

原因

因为使用了Git对本博客的源码进行版本控制和在本地和服务器之间同步，且没有进行单独部署，所以Git生成的.git文件夹就暴露在了公网上。虽然目录关闭了索引，但是可以通过HEAD信息构造访问URL下载.git中objects文件夹下的内容，从而实现重建源代码，获取敏感信息。

原来这是个几年之前就被发现的问题，而且网上早就有对应的问题利用脚本工具。

影响

简单的说，这个问题最直接的影响就是泄漏Web程序的源代码。

泄漏Web程序源代码，尤其是生产环境中的Web源代码是非常严重的，首先源代码中大概率包含了连接数据库的用户密码等敏感信息，其次非开源的商业源码可能就这样被他人窃取，再者有的站长可能为了方便管理留有Webshell之类的后门…… 总之，Web源代码泄漏算是非常严重的安全问题。

解决

问题总是需要解决的，解决这个问题的方法有很多，通过单独部署、限制权限和限制访问都行。在Nginx添加中URL重写判断来禁止访问这个.git目录下的内容：

    rewrite ^/.git/ https://urdomain.com/; #Fix git issues

安全真是的防不胜防，所以配置习惯还是很重要的。好在这次问题对我的影响还算可控：首先博客用的开源软件Typecho，并且config.inc.php文件在ignore文件中，并且每个应用的数据库都有单独的用户名和随机的密码；其实最重要的是博客里面没有什么隐藏的webshell或者资料之类的敏感内容。

总之，还是要感谢一下进行这个全网.git问题扫描，并进行善意提醒的vsmitka，也希望各位检查一下自己的站点是否也存在该问题。

---

最后，附上邮件全文：

邮件全文

Hello,

I'm an independent security researcher and recently I made a huge scan for publicly accessible .git repositories. I would like to notice you I have found this security problem on your sites too.

When you leave the .git folder accessible on the webserver, it is possible to download the source code and it can be a serious problem. Many of this repositories contain sensitive data like DB credentials, API keys and it is possible to explore the structure of the application to find more security problems (e.g. hidden endpoints like open uploaders and so on). This problem is often missed because when you try to open /.git, the 403 is returned usually, but it is only the result of missing index.html. I gained your e-mail from the repository - from list of commits in /.git/logs/HEAD - you can take it as a proof of concept.

I recommend you to delete the repository if you don't need it, limit access to it, or even better - change the deployment workflow and don't leave the repository in a publicly accessible folder.

This e-mail is auto-generated and I'm sorry if your team have obtained unpleasant amount of this notices, however it is the easiest way to contact a relevant person. I also apologize for possible false positive if your project is already public on the GitHub or contains only few static files - I wasn't able to recognize them without a deeper repository inspection.

You can find more details about this vulnerability, about the scan and about me on my blog https://smitka.me.

If you think these scans are helpful, please consider a small donation for future projects.

Regards and greetings from the Czech Republic,

Vladimir Smitka

Twitter: @smitka
LinkedIn: vsmitka
Blog: https://smitka.me