你的网站可能正通过.git或.svn目录泄露源代码、数据库配置和服务器路径,这相当于把后门钥匙放在了门口。攻击者只需在浏览器地址栏输入"yoursite.com/.git/"或"yoursite.com/.svn/",就可能下载全部版本控制文件,利用工具还原出完整代码库。解决的核心思路有两个:立即屏蔽外部对这些目录的访问,并彻底从生产服务器中移除这些版本控制文件夹。
为什么.git/.svn目录会变成严重的安全漏洞?
Git和SVN是开发人员管理代码版本的工具,会在项目根目录创建.git或.svn隐藏文件夹,里面包含完整的版本历史记录。在开发环境中这很正常,但问题出在部署时:很多团队直接用"git clone"或"svn checkout"把代码拉到服务器,或者打包时忘了排除这些目录。于是,这些本应留在开发机的文件夹就被暴露在了公开的Web目录下。攻击者访问这些目录时,如果服务器配置不当(例如Apache的Options Indexes被开启),可能会直接列出文件清单;即使不列清单,只要文件能被访问,专用扫描工具(如DVCS-Pillage、GitHack)就能递归下载所有对象文件,重建出项目的完整源代码、历史提交记录、甚至包含密码和API密钥的配置文件。
如何检测你的网站是否存在此漏洞?
手动检测最简单:直接在浏览器中访问"https://你的域名/.git/HEAD"。如果返回类似"ref: refs/heads/master"的文本,就证明.git目录可被访问。同样,访问"/.svn/entries"也能检测SVN漏洞。更专业的方法是使用命令行工具curl,执行
curl -I https://你的域名/.git/config
查看HTTP返回状态码,如果是200或403(而非404),则说明该路径存在且可能泄露信息。自动化扫描工具,如开源项目GitStack Scanner或集成在Burp Suite中的插件,可以更全面地进行递归探测,尝试下载所有元数据。
立即生效的方法:在Web服务器配置中屏蔽访问
在移除目录前,你必须先在Web服务器层面阻止所有对.git、.svn及类似版本控制目录的请求。以下是对主流服务器的配置方法。
对于Apache服务器,你可以在网站根目录的.htaccess文件或虚拟主机配置中添加:
<DirectoryMatch "^/.*/\.(git|svn)/">
Order allow,deny
Deny from all
</DirectoryMatch>这段规则会拒绝所有对以.git或.svn结尾的目录的访问。如果你使用Apache 2.4+,语法略有不同:
<DirectoryMatch "^/.*/\.(git|svn)/">
Require all denied
</DirectoryMatch>对于Nginx服务器,在对应的server配置块内添加:
location ~ ^/\.(git|svn)/ {
deny all;
return 404;
}这条规则会拒绝访问并返回404状态,避免向攻击者透露目录是否存在。更严格的方案是屏蔽所有以点开头的隐藏文件/目录:
location ~ /\. {
deny all;
access_log off;
log_not_found off;
}对于IIS服务器,你可以在web.config文件的<system.webServer>部分添加请求过滤规则:
<security>
<requestFiltering>
<hiddenSegments>
<add segment=".git" />
<add segment=".svn" />
</hiddenSegments>
</requestFiltering>
</security>修改配置后,务必重载或重启Web服务使规则生效。
根治方案:从生产服务器中彻底移除版本控制目录
屏蔽访问只是治标,治本之道是将这些目录从线上服务器中彻底删除。切勿简单地在服务器文件管理器里删除,因为容易遗漏。正确的方法是使用命令行或构建脚本。
在Linux服务器上,进入网站根目录,执行:
find . -name ".git" -type d -exec rm -rf {} \;
find . -name ".svn" -type d -exec rm -rf {} \;这条命令会递归查找并删除所有.git和.svn目录。执行前建议先备份或使用
find . -name ".git" -type d
预览找到的目录。
在Windows服务器上,如果你安装了Git Bash或PowerShell,可以使用类似的find命令。原生的PowerShell命令为:
Get-ChildItem -Path "你的网站路径" -Include ".git", ".svn" -Directory -Recurse | Remove-Item -Force -Recurse
最推荐的做法是将移除步骤集成到你的部署流程中。例如,在使用Jenkins、GitLab CI/CD或GitHub Actions进行自动化部署时,在构建脚本中添加清理步骤。一个典型的Shell部署脚本片段如下:
# 构建完成后,进入构建输出目录 cd /path/to/build/output # 删除所有版本控制目录 find . -type d -name ".git" -o -name ".svn" | xargs rm -rf # 再同步到生产服务器 rsync -avz --delete ./ user@production-server:/var/www/html/
这样能确保每次部署的代码都是“干净”的。
进阶防护与最佳实践
除了.git和.svn,还需注意其他版本控制系统的目录,如Mercurial的.hg、CVS的CVS目录。同样,IDE配置文件(如.idea、.vscode)、备份文件(.bak、.swp)和环境配置文件(.env)也应禁止访问。你可以在服务器屏蔽规则中一并添加。
建立强制性的部署清单:
(1)代码仓库中应有.gitignore文件,忽略编译产物和敏感文件;
(2)部署使用“导出”功能(如git archive),而非直接克隆;
(3)使用Docker等容器化部署时,确保镜像构建层不包含版本控制文件;
(4)定期使用安全扫描工具对生产环境进行漏洞扫描。
对于大型分布式团队,建议将“清除版本控制目录”作为安全基线策略写入运维规范,并利用配置管理工具(如Ansible、Puppet)统一在所有服务器上应用屏蔽规则,确保不留死角。
当漏洞已发生:应急响应与后续措施
如果你检测到.git或.svn目录曾被公开访问过,应立即启动应急响应:
(1)按上述步骤立即屏蔽访问并删除目录;
(2)轮换所有可能泄露的敏感信息,包括数据库密码、API密钥、SSL证书、加密盐值等;
(3)审查近期的访问日志,寻找异常IP的扫描请求;
(4)检查代码仓库历史,确认是否有硬编码的凭证被提交过,并在仓库历史中将其清除(虽然繁琐,但必要)。
长远来看,应将此漏洞的检查纳入新项目上线的安全检查流程和现有系统的定期安全审计中。开发与运维团队需要共同树立“生产环境与开发环境分离”的意识,从源头上杜绝将开发工具副产品带入生产环境。
网站安全无小事,一个看似微不足道的隐藏目录,可能就是整个系统沦陷的起点。主动屏蔽与移除.git/.svn目录,是一项低成本、高收益的关键安全实践,必须立即执行并持续监控。
