企业官网建设流程全解析

1. 先搞懂Git，才明白为什么“泄露”会发生

1.1 Git到底在本地存了什么

很多人对Git的印象停留在“它是一个版本控制工具”，日常操作就是git add、git commit、git push，剩下的全靠IDE点按钮。但真正遇到Git泄露问题的时候，你如果只懂这三个命令，会完全不知道从哪儿下手。

Git和SVN这类集中式版本控制最大的区别在于：Git的每个仓库都是一个完整的“本地镜像”。你在本地执行git init或者git clone之后，项目根目录下会产生一个.git文件夹，这个文件夹里保存的不只是“当前版本的源代码”，而是从第一次提交到现在为止的全部提交历史、全部版本快照、全部分支引用、全部提交者信息。换句话说，开发这台机器上曾经出现过的任何代码片段，包括已经删除的文件、写错了又改回来的内容、配置里的数据库密码，都被安静地记录在.git/objects下面。

具体来说，.git目录里几个关键位置：

• config：仓库配置，里面可能有远程仓库地址、用户信息，甚至残留的账号Token。
• HEAD：指向当前分支的引用，通常内容就是ref: refs/heads/master。
• index：暂存区快照，记录了当前已经git add但还没有提交的文件状态。
• objects/：Git的对象数据库，所有的commit、tree、blob都以压缩形式存在这里。
• logs/：所有分支的完整操作记录，包括reset、rebase、checkout的历史。
• refs/：分支和标签的引用。

拿生活打个比方：.git目录就像你家书房里的一本“全屋改造流水账”，不仅记着现在房子长什么样，还记着十年前砸掉的那堵墙、五年前拆掉的阳台、前任业主留下的水管路线图。外人只要拿到这本账本，就能把你家翻个底朝天。

所以，当网站服务器把.git目录暴露出来的时候，攻击者拿到的不是“一份源码”，而是这个项目从出生到现在的完整时间线。很多CTF题目里的flag，就藏在某个已经被“遗忘”的历史提交里。

1.2 导致Git泄露的三类部署现场

Git泄露在真实世界里非常常见，我总结下来，基本就三类原因。

第一类是开发环境打包上线。开发者在本地把项目开发完，直接把整个项目文件夹往服务器上一扔，.git目录也没删。如果Web服务器把项目根目录作为网站根目录，那外部就能通过http://目标/.git/直接访问。

第二类是服务器上用git做自动化部署。很多团队用git pull或者git clone把代码同步到生产服务器，但搞完以后没有把.git目录删掉，或者没有在Nginx/Apache层面对.git、.svn这类隐藏目录做访问拦截。这时候服务器上的“代码副本”带着完整的历史记录，等于把开发仓库明晃晃地摆在了门口。

第三类是Web服务器配置失误。nginx的root配置指到了项目上一级目录，或者Apache的Options Indexes开启了目录列表，导致.git里的文件能被逐个列出来。这种情况下，即使开发者没有刻意上传.git目录，只要公共目录里存在它，就会被扫出来。

这里要强调一个关键点：Git泄露和.git目录本身没有必然的“漏洞”关系，真正的漏洞是Web服务器把不该公开的静态文件目录暴露了出去。Git本身没有安全机制去防止别人读取这些文件，它只管记录版本，不管“谁能看”。所以你在实战里发现带有.git的网站，大概率不是网站被黑了，而是部署流程不规范。

1.3 一次泄露可能暴露多少东西

如果你的目标是CTF拿flag，那Git泄露通常能让你拿到源码，然后在源码里找答案。但如果是真实环境，一次Git泄露能暴露的东西远不止源代码：

• 全部历史版本的源码，包括被删除、被掩盖的敏感功能。
• config文件里的数据库连接串、第三方API密钥、后台登录凭证。
• 测试环境和正式环境的差异代码，比如测试环境里开了调试模式。
• 提交者姓名、邮箱、提交时间，可以用于后续钓鱼或社工。
• 未公开的内部接口文档、自动化脚本中的用户名密码。

所以Git泄露在OWASP和各类安全测试里都被列入“信息泄露”类高危问题，危害程度一点都不低。

2. 环境准备：Git安装、dirsearch与githack

2.1 先把Git装好，完成基础配置

用Git处理泄露仓库之前，你自己机器上得先有一个能用的Git环境。

Windows用户最省事的方式是去Git官网下载Git for Windows，一键安装，装的时候默认选项即可，但有一个点要注意：在“Adjusting your PATH”这一步，建议选“Git from the command line and also from 3rd-party software”，这样稍后在cmd或者PowerShell里也能直接敲git。如果选错了，装完以后在cmd里敲git会提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。

Linux用户更简单，Debian系执行apt install git，RedHat系执行yum install git，装完验证一下版本：

git --version

正常会输出类似git version 2.39.2的内容。

装完Git之后，第一件事是配置用户名和邮箱，否则后续操作提交时会报错：

git config --global user.name "yourname" git config --global user.email "youremail@example.com"

这两个配置看起来只是提交信息，但在分析Git泄露仓库的时候有一个实际的用途：如果你下载下来的仓库需要继续执行git reset、git checkout这类操作，部分版本会校验用户信息，配置好可以避免一些莫名其妙的报错。

另外，我要特别推荐Windows用户把Git Bash当成主力终端。当你以后要跑dirsearch、githack这类Python脚本时，Git Bash里路径处理、权限表现和Linux环境更接近，能少踩很多坑。

2.2 dirsearch：用字典爆破目录

Git泄露的入口是发现.git目录，而发现目录最通用的思路就是目录扫描。

dirsearch是目前使用频率最高的Web目录扫描工具之一，Python编写，跨平台，字典丰富，支持多线程，对CTF和授权测试都足够用。安装很简单：

git clone https://github.com/maurosoria/dirsearch.git cd dirsearch pip install -r requirements.txt

基本用法：

python3 dirsearch.py -u http://目标地址/ -e html,php,txt,bak,tar -x 403,404 --random-agent

参数含义：

• -u：目标URL，注意带不带末尾斜杠会影响结果，建议带上。
• -e：要检测的扩展名，CTF里常见的是php、html、txt、bak、zip、tar。
• -x：排除的状态码，比如403和404可以排除，减少噪音。
• --random-agent：随机User-Agent，避免被WAF拦截。

dirsearch扫描的原理说白了就是拿一批常见目录名和文件名去请求目标，然后根据Content-Length、状态码、响应头判断是否存在。所以它的检出能力很大程度依赖字典质量。实际CTF里，.git这种目录几乎每个扫描器都会测，命中率极高。

如果你用不惯dirsearch，gobuster、ffuf、御剑一类工具也可以替代，但方向一致：Web目录爆破。

2.3 githack：把.git还原成源码

发现.git目录之后，最忌讳的操作是拿浏览器直接访问/.git/objects/xxx一个文件一个文件地下。原因有两点：第一，Git对象文件数量庞大，手动下载不现实；第二，即使你把所有文件下载下来，它们也是压缩过的二进制对象，不是直接能看的源码。

正确做法是用专门工具解析.git目录结构并重建项目。最经典的是githack，项目地址是lijiejie/GitHack，clone下来就能用：

git clone https://github.com/lijiejie/GitHack.git cd GitHack python3 githack.py http://目标地址/.git/

它会自动遍历.git下所有可访问的文件，下载并利用Git自身的逻辑重建工作区文件。重建完以后，你会在当前目录下得到一个完整的项目文件夹，里面就是还原出来的源码。

后来还有一个增强工具叫GitHacker，兼容性更好，针对一些不完整、缺失对象的情况做了处理：

git clone https://github.com/WangYihang/GitHacker.git cd GitHacker python3 githacker.py --url http://目标地址/.git/ --output-folder ./result

我个人建议两个工具都装上，因为有些靶场或真实站点对某些工具的请求特征做了防护，换着用能有效避免扫描行为被识别。

2.4 需要注意：工具不是万能的

很多人第一次用githack会发现，下载下来的文件夹里只有一部分文件，或者干脆是空的。这种情况通常有三种原因：一是目标.git目录不完整，部分对象缺失；二是服务器做了访问频率限制，工具请求太快被拒绝；三是Web服务器对.git目录做了部分拦截，比如只拦截了config、HEAD这些关键文件。遇到这种情况，先别急着换工具，可以先手动访问/.git/config和/.git/HEAD看看是否正常返回，再决定下一步。

3. 实操：在CTFHub上把Git泄露完整打一遍

3.1 为什么选CTFHub来做实验

练习Git泄露，最怕的就是拿真实网站练手，这既有法律风险，也不符合安全测试的基本伦理。CTFHub是一个在线CTF靶场平台，它的技能树里专门有一块“信息泄露”，其中“Git泄露”分了三道题：Log、Stash、Index。这三道题正好对应了Git泄露最常见的三种利用方式，非常契合实战中会遇到的情况。

靶场地址我就不贴了，你搜索“ctfhub 技能树 信息泄露”就能找到。每道题打开后会给一个独立域名和端口，答题环境是隔离的，随便折腾不影响到别人。

3.2 常规Git泄露（Log）：提交历史才是宝库

先打开“Git泄露-Log”这题，题目环境会给你一个URL，类似http://challenge-xxxxx.ctfhub.com:10080/。

第一步，用dirsearch确认.git目录是否存在：

python3 dirsearch.py -u http://challenge-xxxxx.ctfhub.com:10080/ -e html,php,txt,bak --random-agent

跑完之后重点看状态码200且路径为/.git/的记录。dirsearch扫到目录后可能出现两种结果：一种是直接列出.git下文件列表，另一种是只显示目录存在但禁止列目录。后者也很正常，因为很多站点会关闭目录列表功能。

第二步，手动验证：

访问http://challenge-xxxxx.ctfhub.com:10080/.git/HEAD，如果返回ref: refs/heads/master，基本确认Git泄露成立。

第三步，用githack下载完整仓库：

python3 githack.py http://challenge-xxxxx.ctfhub.com:10080/.git/

命令跑完后，同目录下会出现一个以域名命名的文件夹，里面就是目标项目的全部源码。切进这个目录，执行：

git log --oneline --all

这时候能看到该仓库的完整提交记录。Log这道题的考点就在这：开发者可能在某次提交里写了flag，然后又把它改掉了，但历史提交里仍然保留着原始内容。我们只需要找到包含可疑内容的提交：

git log --all -p --grep="flag"

或者直接逐个查看提交差异：

git show <commit_id>

通常情况下，flag就藏在某次提交的代码注释、配置文件或者输出函数里。执行git show时如果提交信息里正好有flag{...}相关字样，一眼就能看到。

这道题的命名“Log”指的就是攻击面在git log，学习的时候可以记一下：提交历史是最好的信息藏身处。

3.3 Git泄露（Stash）：开发者的临时改动被留下了

第二道题是“Git泄露-Stash”。

Stash在Git里的含义是“储藏”，开发者临时有别的任务，但手头的改动还没做完，又不想提交，于是执行git stash把改动暂时收起来。问题在于，很多开发者把东西stash之后就忘了，这个“半成品”就永远留在了.git目录里。

githack下载这个仓库后，第一步先看stash列表：

git stash list

如果输出类似stash@{0}: WIP on master: xxxxxxxxx，说明存在未被恢复的暂存改动。接着查看stash内容：

git stash show -p stash@{0}

-p参数会显示具体的diff内容，flag往往就加在这个diff里。如果这个stash里没有，可以把所有stash都看一遍：

git stash show -p stash@{1}

我在实际做这题的时候还试过git stash show stash@{0} --name-only先看看涉及哪些文件，再决定要不要看完整内容，这样更高效。

有一个细节要注意：在某些版本的Git中，花括号在shell里有特殊含义，所以在bash里执行git stash show -p stash@{0}时可能被解释成参数扩展，报“bad substitution”之类的错。这时候用单引号包起来就行：

git stash show -p 'stash@{0}'

3.4 Git泄露（Index）：从暂存区里“捞”回被删除的文件

第三道题是“Git泄露-Index”。

Index是Git的暂存区，记录了“已经add但尚未commit”的文件状态。有些时候，开发者把flag文件git add到了暂存区，但后来因为某种原因又把它从工作区删了，而且没有重新提交。这时候，这个文件的信息已经在Git对象库里了，只是工作目录里没有。

githack下载后，第一步用：

git ls-files

这个命令列出暂存区里所有的文件。如果看到一个类似flag.txt或flag.php的文件，但当前工作目录里不存在，那就说明flag被“藏”在index里。

恢复方式有两种：

git checkout -- flag.txt

或者：

git cat-file -p <blob对象id>

第二种方式需要先通过git ls-files --stage查一下对应文件的blob对象ID，然后直接读取对象内容。两种方式都能拿到flag。

这三道题的递进关系很明显：Log考的是提交历史，Stash考的是储藏记录，Index考的是暂存区。三者覆盖了Git本地仓库中几个最容易残留敏感信息的位置。有兴趣的话可以自己做个实验：在本地仓库里分别执行git commit --amend、git stash、git add后删除文件再git reset，然后看看.git目录里留下了什么，这样能更直观地理解这些攻击面的来源。

3.5 完整利用流程小结

把这套流程固化下来，以后遇到Git泄露无论是不是CTF题，都按这个顺序走：

1. 目录扫描：用dirsearch或手工请求/.git/HEAD、/.git/config确认目标是否存在Git泄露。
2. 仓库下载：用githack或GitHacker把.git目录下载到本地并重建。
3. 信息搜集：依次执行git log --all --oneline、git stash list、git ls-files，把历史提交、储藏区、暂存区的信息全部拉出来。
4. 内容审计：用git show、git stash show -p、git cat-file -p定位敏感信息，重点看配置文件、注释、密钥和flag关键词。
5. 扩展利用：如果目标是真实站点，还需要检查config文件里的远程仓库地址有没有泄露其它仓库的访问权限，检查提交者邮箱是否暴露了内部账号信息。

这套流程其实不复杂，难的是每一步都做到位。很多人扫到.git目录就急着用工具一把梭，下载完也不知道该看什么，最后空手而归。按部就班做，基本都能拿到结果。

4. 常见问题与排查技巧实录

4.1 命令提示“无法将git识别为cmdlet”

Windows上装完Git后在PowerShell里敲git --version报错，提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”，这个我在新环境里遇到过很多次。原因就一个：Git可执行文件路径没有加入系统环境变量PATH。

解决办法有两个：

一是重装Git，在“Adjusting your PATH”那一步选择第一项或第二项。

二是不重装，手动添加环境变量。找到Git安装目录下的cmd文件夹，比如C:\Program Files\Git\cmd，然后“系统属性 -> 环境变量 -> Path -> 编辑 -> 新建”，把这个路径加进去，保存后重开终端。

如果不想改环境变量，也可以用Git Bash，它自带完整环境，不需要单独配置PATH。

4.2 dirsearch扫不到.git目录

排除目标本身没有Git泄露的情况，扫不到.git目录多半是以下原因：

• 字典里没有.git这条记录。虽然大部分主流字典都有，但个别精简字典可能漏掉。建议扫描时再手工请求一次/.git/HEAD确认。
• 目标做了大小写敏感访问控制。Git目录正常是小写.git，但有些站点会把/.Git/、/.GIT/的请求拦截掉，这时候要具体看服务器配置。
• 扫描线程开太高，触发了WAF拦截。dirsearch默认会输出大量404噪音，如果目标有安全设备，你的扫描行为可能被识别并拦掉。讲到这里，我建议扫描时加-x 403,404排除无效状态码，同时降低线程数到10以内，避免被视为攻击。

验证.git是否存在，最快的不是等扫描完，而是直接访问这两条URL：

/.git/HEAD /.git/config

这两个文件是Git仓库的必备文件，如果返回内容符合预期，哪怕dirsearch没扫到，也基本可以确定目标存在Git泄露。

4.3 githack下载失败、卡住或文件不完整

这类问题在实战里最磨人。githack原理是逐文件请求目标服务器，如果目标网络慢、文件多，或者服务器限速，很容易超时。

处理方法：

• 换GitHacker工具再打一次，它的断点续传和容错做得更好。
• 手动下载关键文件，掌握这个思路对理解Git原理也有帮助。.git目录里最重要的是objects/下的对象文件和refs/heads/下的分支引用，如果工具下载不完整，可以用脚本遍历objects/info/packs以及objects/xx/目录手工下载，然后放到本地仓库对应的位置，再用git fsck检查仓库完整性。
• 缩小范围：如果只是CTF里找flag，可以先下载.git/logs/和.git/refs/，这两个目录记录了分支指向和操作历史，配合对象下载可以更快定位flag所在的提交。

4.4 下载了源码但执行git命令没反应

githack重建出来的仓库有可能不是一个“完整仓库”，因为它重建的主要是工作区文件，不是标准的Git裸仓库。如果你发现git log执行后没有任何输出，先检查一下是否缺少了应有的目录结构。

常见问题是：git log默认从当前分支HEAD开始查找，但如果仓库的HEAD内容被还原成了refs/heads/master，而refs/heads/master指向的commit对象没有下载下来，就会表现为“无提交记录”。这时候试试：

git fsck --lost-found

它可以列出对象库里所有没有被引用的对象，flag有可能藏在这些“孤儿对象”里。

4.5 最容易忽视的两个细节

第一个细节：别忘了查看.git/config。这个文件里经常有远程仓库地址，如果泄露的仓库是从内网Git服务器clone的，地址本身就能暴露内网域名或IP。在一些渗透测试场景里，这个信息比源码还值钱。

第二个细节：不是所有信息泄露都以.git/开头。有些站点把.git目录打包成了www.zip、backup.tar放在网站根目录，或者用了git bundle、git archive导出了包。所以扫描的时候，除了扫描.git目录，也要关注zip、tar、bak、rar这些备份文件。ctfhub里还有“备份文件下载”这个分类，思路是相通的。

4.6 说不完的避坑心得

我在线下带着新人做这道题的时候，最常说的一句话是：遇到Git泄露，先看log，再看stash，最后看index，顺序不要乱。因为这三类信息出现的频率和对解题的帮助是递减的，Log最容易出结果，Index最隐蔽。如果一上来就钻index，很可能浪费时间。

还有一个使用习惯：拿到githack还原的源码后，不要直接在“下载目录”里乱翻，先执行git log --all --oneline看一遍提交时间线。很多flag不是写在当前代码里，而是写在“某一次”历史提交里，你要做的是对比差异，不是看最终版本。

最后再分享一个小技巧

如果你以后在工作中遇到真实站点疑似Git泄露，可以先试试请求/.git/objects/info/packs。如果这个文件存在且列出了pack文件名，说明这是一个经过gc压缩的仓库，对象可能都在一个pack文件里。这种情况下githack这种逐文件下载的工具大概率会失效，因为pack文件体积很大而且通常是二进制流，手动分析难度也高。

这时候更好的选择是直接尝试用curl把pack文件拉下来，然后在本地用git index-pack之类的命令去解析。当然这属于进阶玩法了，CTF里很少遇到，但真实环境里遇到两次，就能体会到这个技巧的价值。我个人的体会是，Git泄露之所以好玩，是因为它考验的不是某个单一漏洞的利用，而是你对Git这个工具本身机制的理解程度。把.git当成一本“开发流水账”去读，比背一百条命令都管用。