通过 git 凭证验证端点进行认证 SSRF 并进行响应体外泄

通过电子邮件于 2026 年 6 月 14 日报告: 我已经在当前版本 v4.1.3 中发现了 git 凭证验证端点(`POST /kapis/[resources.kubesphere.io/v1alpha2/git/verify]`)中的一个服务器端请求伪造(SSRF)漏洞。该端点通过内置的`authenticated`全局角色授予所有经过身份验证的 KubeSphere 用户，其中包括明确的 RBAC 规则，允许在 `[resources.kubesphere.io/git]` 上执行`create`操作。不需要额外的工作空间或项目成员资格。处理器将调用者提供的`remoteUrl`字段直接传递给 go-git 的`origin.List()`，该方法使用 ks-apiserver 的网络身份执行出站 HTTP 请求(`GET <remoteUrl>/info/refs?service=git-upload-pack`)。当目标返回非 2xx 响应时，go-git 会读取 HTTP 响应体并将其包含在错误字符串中。然后，处理器将此错误序列化为 JSON 响应中返回给调用者的`message`字段。因此，攻击者可以访问内部主机和服务，并从它们的 HTTP 响应中泄露部分内容。我通过对实际 kubesphere 仓库代码的内部测试来验证了此行为。测试表明，内部服务在 `/info/refs` 上接收了请求，并返回了原文的响应体`INTERNAL_SENSITIVE_DATA=secret123`，作为 API 错误响应的一部分。该端点还接受一个可选的`secretRef`字段，它指定命名空间和名称的 Kubernetes 秘密。ks-apiserver 服务帐户具有整个集群的秘密读取权限；它会从秘密中提取凭证，并通过 HTTP 基本身份验证将其发送给调用者提供的`remoteUrl`。这使得任何经过身份验证的用户都可以通过将远程 URL 指向受攻击的服务器来从任何命名空间(包括`kube-system`)的秘密中泄露凭证。建议的修复措施: 在调用 go-git 之前，对`remoteUrl`进行验证，确保其符合可配置的允许的主机名模式列表(或者使用类似 Go 的`dialer.Control`模式的连接时拨号钩来拒绝私有 RFC 1918、链路本地和回环地址)。此外，还要添加所有权或 RBAC 检查，以便命名空间 N 中的秘密引用`secretRef`只适用于拥有该命名空间中的`get secrets`权限的调用者。