Coolify项目中Gitlab Webhook未验证Secret的安全隐患分析

Coolify是一个开源的云部署和管理平台，它允许用户通过Git仓库的Webhook来自动触发应用的构建和部署。在最近的安全审计中发现，Coolify v4.0.0-beta.360版本中存在一个重要的安全问题：Gitlab Webhook接口在未设置Token的情况下可以被任意触发。

问题原理

在正常的Webhook安全机制中，Gitlab服务会配置一个Token密钥，用于验证Webhook请求的合法性。Coolify平台本应验证这个Token，但实际实现中存在逻辑缺陷：当用户没有为Gitlab仓库配置Webhook Token时，平台会跳过验证步骤，直接处理请求。

这种设计问题使得攻击者可以：

1. 通过猜测或枚举获取Coolify实例的Webhook端点URL
2. 构造伪造的Gitlab推送事件请求
3. 在不知道Token的情况下触发应用的重新部署

问题验证

攻击者只需构造一个简单的HTTP POST请求，包含以下关键元素：

• 目标应用的Gitlab仓库路径（user/repo-name格式）
• 基本的推送事件数据结构
• 空的X-Gitlab-Token头

示例请求如下：

{
  "object_kind": "push",
  "event_name": "push",
  "ref": "refs/heads/main",
  "project": {
    "path_with_namespace": "victim/repo",
    "url": "[e-mail]:victim/repo.git"
  }
}

服务器会返回成功响应，表示部署已加入队列，完全绕过了应有的安全验证。

安全影响

该问题可能导致以下风险：

1. 未经授权的部署触发：攻击者可以强制目标应用重新部署
2. 资源滥用：通过频繁触发部署消耗服务器资源
3. 供应链攻击：如果结合其他问题可能导致恶意代码注入
4. 服务中断：通过持续触发部署造成服务不稳定

修复方案

Coolify开发团队已经解决了此问题，主要改进包括：

1. 强制要求所有Gitlab Webhook请求必须包含有效的Token密钥
2. 当Token未配置时，拒绝所有Webhook请求并记录安全事件
3. 增加输入验证，确保请求数据符合预期格式

最佳实践建议

对于使用Coolify或其他类似平台的管理员，建议：

1. 始终为Webhook配置强密码Token
2. 定期审计Webhook配置和访问日志
3. 将Coolify实例升级到最新安全版本
4. 考虑使用IP白名单限制Webhook来源
5. 监控异常的部署触发行为

这个案例提醒我们，在实现自动化部署系统时，必须严格验证所有外部输入的合法性，特别是涉及关键操作如应用部署的接口。安全设计应该遵循"默认拒绝"原则，而不是"默认允许"。