简介Git_Extract是一套基于Python3的Git目录泄露检测与提取工具包专门面向安全测试人员、开发者和运维人员旨在解决Web服务器中.git目录意外暴露所导致的信息泄露问题。通过扫描公开目录工具能解析提交历史、分支与文件内容帮助用户快速确认敏感信息是否外泄并采取应急加固措施。压缩包共10个文件包含5个Python源码脚本、4个编译生成的pyc文件及1个Markdown说明文档源码脚本分别承担数据解析、索引处理与通用辅助功能整体仅13KB轻量易部署。目前已有938人学习下载适合具备Python基础、关注Web安全的入门与进阶使用者。通过该工具读者可以掌握Git泄露攻击的检测与数据提取思路学会利用版本元数据分析源码结构并据此加固服务器访问控制策略避免源代码、账户口令等关键数据被恶意获取。 拿站点的时候突然发现/.git/目录能直接访问那一瞬间的兴奋感做过安全测试的人都懂。但你很快会发现浏览器里只能看到一堆十六进制文件名真正的源码根本点不出来。这时候手里要是有个趁手的Git_Extract.zip情况就完全不一样了——解压、配环境、跑脚本三步就能把整个项目的历史版本连同当前代码一起挖出来。这篇博文从实际测试视角出发完整拆解Git_Extract.zip这个工具包的使用链路先说清楚为什么.git泄露等于源码裸奔再讲工具包解压和运行环境的坑然后是恢复源码的核心操作最后是排错思路和防御建议。无论你是刚接触目录泄露的新手还是被各种报错折磨过的老手这篇都能直接对着抄作业。1. 为什么一个 .git 文件夹就能让整个项目裸奔1.1 Git 对象模型对恢复源码意味着什么很多人觉得.git目录只是存了一些提交记录丢了也无所谓。这是最大的误解。Git 的核心是对象数据库所有文件内容、目录结构、提交历史全部以对象的形式存在.git/objects/下面。每个对象都有一个 SHA-1 哈希值当作文件名内容经过 zlib 压缩存储所以你在浏览器里看到的是乱码一样的文件名其实它们是完整的数据块。当你执行git add时文件内容被保存为blob 对象git commit时目录结构被保存为tree 对象提交信息被保存为commit 对象。这三类对象互相引用、层层嵌套构成了完整的时间线。只要.git目录在就算工作区文件被删光也能通过git checkout或者脚本解析对象数据库把每一个历史版本的文件全部恢复出来。这正是Git_Extract.zip这类工具的核心原理它模拟 Git 自身的对象解析逻辑下载.git/objects/下的对象文件识别 commit、tree、blob再按照 tree 结构重建出源码目录。不需要服务器端执行代码不需要数据库权限只要 HTTP 能读到.git下的文件源码就保不住了。1.2 目录泄露的几个常见入口从实际经验看.git泄露最常见的是这几种情况Web 服务把项目根目录直接指向了仓库根目录但没有禁止访问.git文件夹。Nginx、Apache、IIS 默认都不拦直接暴露。CI/CD 流水线把代码部署到了 Web 目录部署后没有删除.git。很多自动化脚本图省事git clone到站点根目录就结束了。备份文件或压缩包被搜索引擎收录比如www.zip、backup.tar.gz里面往往带了完整的.git目录。前端项目构建产物和源码放在同一个目录.git随着静态资源一起被发布到了 CDN 或对象存储。判断方法很简单浏览器访问https://target.com/.git/config如果返回类似[core] repositoryformatversion 0的内容基本就实锤了。需要注意的是有的服务器会屏蔽点号开头的路径但通过%2e编码、/./路径穿越等方式可能绕过这不是本文重点但你要知道漏网之鱼很多。2. 解压与运行环境补全Git_Extract.zip 的落地姿势2.1 环境选择Kali 还是 WindowsGit_Extract.zip里通常是 Python 脚本加说明文档可能还带了一个轻量的 Git 配置模板。工具本身跨平台但我强烈建议在 Linux 或 Kali 环境下跑。原因不是脚本不兼容 Windows而是目标站点普遍在国外网络环境下Linux 下用curl、wget、python3的组合最少折腾遇到超时重试也更好写。Windows 下跑也不是不行前提是你把环境补全Python 3.8并且python命令能被终端识别。Git for Windows 安装好并勾选 Add to PATH。如果没有curl直接装 Git Bash里面自带。装了 Git Bash 后很多Git_Extract.zip里的脚本就能直接用bash跑了避免 cmd 的编码问题。我见过太多人卡在这一步明明工具包解压了脚本一运行就报git 不是内部或外部命令。这就是 PATH 没配好。2.2 解压报错与修复热搜词里那些 failed to copy spatial iop zip、could not find eocd 看着吓人其实就是 zip 文件解压失败的典型报错。EOCD 是 End of Central Directory 的缩写位于 zip 文件末尾记录了解压所需的目录索引。如果unzip提示could not find eocd说明文件被截断了或者下载不完整。遇到这种情况别急着删除重下先检查文件大小如果压缩包下载到一半断了用ls -l看大小是否和页面标注一致不一致就重新下载。如果确认大小没问题还是报 EOCD用zip -FF damaged.zip --out repaired.zip尝试修复它能扫描文件把能恢复的条目重建一个可解压的包。Windows 下也可以直接右键用 WinRAR 的修复压缩文件功能原理一样。还有一类坑是中文文件名乱码。Git_Extract.zip里的脚本文件名可能是英文的但说明文档如果是中文在 Windows 下解压可能变成乱码。建议用自带 Unicode 支持的 7-Zip 解压别用老旧的右键全部提取。2.3 依赖确认与最小运行清单解压完成后建议按这个清单检查一遍省得运行时报错python3 --version git --version curl --version如果提示缺哪个就装哪个# Debian/Ubuntu/Kali sudo apt update sudo apt install python3 git curl unzip -y装完后把Git_Extract.zip里提取出来的脚本放在一个干净的工作目录。我习惯建一个rev/文件夹把工具包的对象 ID 列表文件、Python 脚本都放进去再按目标站点名字建输出目录后面恢复的文件全丢里面方便排查。3. 用 Git_Extract 把源码从 .git 里挖出来核心操作链路3.1 目标探测确认 .git 是否可读跑提取脚本之前先手工确认目标.git目录的权限边界。这一步能省很多无用功curl -s -m 10 https://target.com/.git/config如果返回[core]段落说明至少/config可读。接着再测一下对象文件能不能读# 随便挑一个对象路径试读 curl -s -m 10 -o /dev/null -w %{http_code} https://target.com/.git/HEADHTTP 200 是最理想的情况。如果返回 403 或 404说明服务器对.git路径有过滤纯静态拉取的方式大概率行不通但可以试试路径编码绕过。这些是题外话正文里默认场景是 200。3.2 提取脚本的运行与参数说明Git_Extract.zip里的主要工具是git_extract.py它的工作流程大致如下先请求/.git/index拿到当前索引文件这里记录了工作区所有文件的路径和对应的 blob 对象哈希。再请求/.git/HEAD拿到当前分支引用解析出指向的 commit 对象。根据 commit 对象递归解析 tree 对象结合 index 里的 blob 哈希拼出完整的源码路径和内容。把下载到的对象内容解压按照重建的目录结构写盘。实际运行命令一般长这样python3 git_extract.py -u https://target.com/.git/ -o ./output/参数含义-u目标.git目录的 URL 地址建议结尾带斜杠。-o输出目录脚本会自动创建。-d调试模式打印每个请求的耗时和状态码遇到超时很有用。--depth限制恢复的历史深度比如只恢复最近 3 个提交适合目标对象文件特别多的情况。脚本跑完后./output/下就会出现完整的源码树包括index.html、app.js、config.php这些工作区文件以及.git/的镜像。你可以直接打开源码做代码审计也可以进到./output目录里执行git log看提交历史。3.3 大文件与缺失对象的补救式恢复现实情况没那么理想。目标站点如果部署时间很长.git/objects/里会有大量打包文件.pack单个对象直接下载可能拿不到全部内容。还有的时候脚本跑到一半网络断了对象文件缺失生成的源码树里会出现空文件或乱码。我自己常用的补救方式是本地仓库重建法cd ./output # 先看脚本把 .git 恢复到什么程度 ls -la .git/objects/pack/ # 如果拿到了 .pack 文件直接进本地仓库解包 git verify-pack -v .git/objects/pack/*.idx | head -20如果脚本能下载到.pack和.idx文件就可以用git index-pack重建索引然后git fsck --full检查对象完整性。缺失的对象无法凭空恢复但因为 Git 对象之间有引用关系很多文件即使缺失当前版本也能从历史提交里找回上一版。我用这个思路不止一次捞回了脚本漏掉的关键配置文件。4. 常见报错与误判EOCD、死链、大文件拉不动4.1 zip 解压类报错Git_Extract.zip本身如果下载不完整运行前就会卡在解压环节。除了前面说的 EOCD 错误还有一个很常见的提示是invalid zip archive原因通常是文件被当成文本格式传输过二进制内容被改坏了。那种情况下优先找原始下载链接重下别花时间修。如果你手里的是一个加密 zip碰到zip 密码移除暴力破解的需求我的建议是先想清楚密码是不是常见弱口令比如123456、password、域名本身。工具方面可以用zip2john导出哈希再交给john跑字典速度比纯 GPU 破解快得多。不过这是另一条支线和Git_Extract本身关系不大多数安全测试场景用不上。4.2 git 命令类报错恢复过程中最常报的 git 制错误是fatal: not a git repository (or any of the parent directories): .git这说明你当前目录根本不是仓库或者.git路径不对。检查ls -la是否真的有.git目录。git: remote-http is not a git command这是 Git 没装完整缺少远程助手模块重装 Git 即可。could not read from remote repository工具脚本尝试访问远程仓库地址但网络不通。遇到 git 类报错先别怀疑工具脚本把环境变量GIT_SSL_NO_VERIFY1加上试一次。很多目标站点的证书是自签的Git 默认严格校验会直接拒掉加上这个变量能避免大量超时和握手失败。4.3 提取结果异常的排查思路脚本报成功完成但产出文件数量明显不对这种情况最容易让人懵。我的排查顺序是看日志里 HTTP 状态码。如果大量 403 或 429说明目标有 WAF 或者反爬需要降低并发加请求间隔。看对象文件大小。下载下来的对象如果都是 0 字节或几百字节的报错页面说明被服务器拦截了不是工具问题。对比 index 文件和实际目录。/.git/index能读到时里面列出的文件名就是一份清单对比恢复出来的文件就能定位哪些对象没有拉到。还有一次我跑了半天脚本恢复出来的index.html打开全是乱码最后发现是编码问题——Git 默认把文件内容按二进制存储脚本写盘时却用了文本模式导致换行符被转换。解决办法是在脚本里以wb二进制模式写文件。如果你的工具包没修这个 bug可以自己改一下下载文件的写入逻辑。5. 拉完代码之后授权边界与让泄露不再发生的防御建议5.1 授权与报告的基本底线用Git_Extract.zip恢复源码这件事本质是安全测试中的信息收集环节只允许在你有明确授权的目标上执行。自己搭的靶场、SRC 平台授权的项目、客户签了授权书的渗透测试这些场景随便用。没有授权直接对线上站点跑无论目的是什么都越过了合规红线。报告里我一般会这样写泄露路径https://target.com/.git/config可公开访问。影响范围整个项目源码、提交历史、数据库连接配置、密钥信息。复现步骤访问 URL、查看源码、执行恢复工具。修复建议Web 服务器禁止访问.git目录、部署流程剔除仓库目录。这样写的好处是对方安全团队能快速理解问题严重性修复时也有明确方向。5.2 几行配置堵住 .git 泄露作为开发或运维避免这种问题其实很简单。Nginx 下加一段拒绝规则location ~ ^/.*\.git { deny all; }Apache 下在.htaccess或虚拟主机配置里加RedirectMatch 404 /\.git如果用的是对象存储 CDN那就从源头解决发布产物永远走构建目录不要直接发布仓库目录。git archive可以导出干净的快照git archive --formatzip -o release.zip HEAD这样导出的是当前 HEAD 的源码快照不包含.git目录历史提交和对象数据库都不会带出去。如果你是非要把整个仓库放到服务器上不可的场景至少确认git config http.receivepack false关闭匿名写入权限同时把 Web 根目录指向仓库的子目录而不是仓库根目录。多层防护叠加才能避免根目录一开、源码全漏的尴尬。我在实际测试中最深的体感是.git泄露往往不是单点失误而是整个发布流程缺少清理仓库元数据这一步。修好流程比临时加一段 deny 规则更管用。工具能帮你验证结果但真正让数据安全落地靠的还是流程规范。本文还有配套的精品资源点击获取