🦀 ClawHub
Go Vuln Auth Bypass
by @yhy0
Use when auditing Go code involving authentication flows, RBAC policies, Kubernetes admission webhooks, JWT/OAuth token validation, or privilege escalation i...
TERMINAL
clawhub install go-vuln-auth-bypass📖 About This Skill
name: go-vuln-auth-bypass description: "Use when auditing Go code involving authentication flows, RBAC policies, Kubernetes admission webhooks, JWT/OAuth token validation, or privilege escalation in cloud-native infrastructure. Covers CWE-287/863/269/284/285/862. Keywords: authentication bypass, authorization bypass, RBAC, admission webhook, JWT, OAuth, privilege escalation, Rancher, Kyverno, impersonation, namespace isolation, middleware auth"
Go Auth Bypass Vulnerability Patterns (CWE-287/863/269/284/285/862)
当审计 Go 代码中涉及认证流程、RBAC 权限检查、K8s admission webhook、JWT/OAuth 验证时加载此 Skill。
Detection Strategy
通用检测模型，适用于 Go 云原生生态中认证/授权绕过的所有变体。
Sources（攻击入口）：
Authorization, Impersonate-User, Impersonate-Group）authorization, custom auth headers）id_token, access_token, state parameter）/v3/clusters/:id/proxy）Sinks（受保护资源/操作）：
client-go Create/Update/Delete）v1.Secret 对象）ClusterRoleBinding 创建, RoleRef 修改）allow/deny 决策Sanitization（认证/授权屏障）：
Use(), gin Use(), echo middleware chain）SubjectAccessReview, SelfSubjectAccessReview）golang-jwt/jwt/v5 的 Parse + WithValidMethods）UnaryInterceptor, StreamInterceptor）cattle.io webhook admission）检测路径：
搜索认证/授权模式的 Grep 模式：
# K8s admission webhook — 检查是否正确拒绝请求
grep -rn "admission.Response\|admission.Allowed\|admission.Denied" --include="*.go"
RBAC 检查
grep -rn "SubjectAccessReview\|SelfSubjectAccessReview\|authz" --include="*.go"
JWT 解析
grep -rn "jwt.Parse\|jwt.ParseWithClaims\|token.Valid" --include="*.go"
OAuth state 参数
grep -rn "oauth\|OAuth\|state.*param\|csrf.*token" --include="*.go"
HTTP 中间件注册
grep -rn "\.Use(\|\.Group(\|middleware\.\|interceptor" --include="*.go"
Rancher proxy API
grep -rn "proxy.*handler\|proxyRequest\|cloud.*credential" --include="*.go"
K8s impersonation
grep -rn "Impersonate\|impersonate\|as-user\|as-group" --include="*.go"
1. 搜索受保护的资源端点（HTTP handler、gRPC method、admission webhook handler）
2. 检查是否有认证/授权中间件保护（middleware chain、interceptor、RBAC check）
3. 验证屏障是否可被绕过：
- Admission webhook 在升级过程中是否被临时禁用？
- RBAC 策略是否存在跨 namespace 权限泄漏？
- JWT 验证是否检查了 alg 字段和 audience？
- OAuth state 参数是否正确验证？
- 中间件顺序是否正确（auth middleware 在路由之前）？
- Impersonation header 是否在 API proxy 中被正确过滤？
- ServiceAccount token 的权限范围是否过宽？
4. 若无屏障或屏障可被绕过 -> 标记为候选漏洞
Detection Checklist
failurePolicy 设为 Ignore（failOpen）时 webhook 故障会导致请求被放行。namespaceSelector 配置不当可能导致特定 namespace 绕过 webhook 检查。务必验证 admission request 的来源（TLS 证书）防止伪造请求。apiCall 是否使用了 ServiceAccount 的集群级权限访问其他 namespace 的资源？jwt.Parse() 是否指定了 jwt.WithValidMethods([]string{"RS256"})？是否检查了 aud/iss/exp claims？state 参数与 session 中存储的值一致？是否存在 token 交换时的 TOCTOU？UnaryInterceptor 认证链？是否有 method 被排除在外？r.Group().Use(authMiddleware) 是否覆盖了所有子路由？Impersonate-User/Impersonate-Group header？低权限用户是否能通过 proxy 冒充高权限用户？cluster-admin 权限？是否遵循最小权限原则？False Positive Exclusion Guide
以下模式不是此类漏洞：
_test.go 文件中使用 fake.NewSimpleClientset() 跳过认证/healthz、/readyz、/livez 不需要认证是正常行为/metrics 在 Prometheus 架构中通常不需要认证（需确认网络隔离）以下模式需要深入检查：
admission.Allowed("") -- 空 reason 的 allow 决策可能是 webhook 的默认放行逻辑if err != nil { return true } -- 认证错误时默认允许是高危模式Next() 在认证检查之前被调用 -- 可能导致后续 handler 在未认证情况下执行ClusterRole 使用 * 通配符 -- resources: ["*"] + verbs: ["*"] 是过宽权限Real-World Cases
详见 references/cases.md（7 个真实案例，需要时加载）。