Go Auth Bypass Vulnerability Patterns (CWE-287/863/269/284/285/862)
当审计 Go 代码中涉及认证流程、RBAC 权限检查、K8s admission webhook、JWT/OAuth 验证时加载此 Skill。
Detection Strategy
通用检测模型，适用于 Go 云原生生态中认证/授权绕过的所有变体。
Sources（攻击入口）：
- - HTTP 请求头部（
Authorization, Impersonate-User, Impersonate-Group） - Kubernetes API 请求（ServiceAccount token, RBAC RoleBinding）
- gRPC metadata（
authorization, custom auth headers） - JWT/OAuth token（
id_token, access_token, state parameter） - Webhook 回调请求（admission webhook, mutating webhook）
- Rancher API proxy 请求（
/v3/clusters/:id/proxy）
Sinks（受保护资源/操作）：
- - Kubernetes API 调用（
client-go Create/Update/Delete） - Rancher 管理 API（集群凭证、cloud credential）
- Secret 读取/修改操作（
v1.Secret 对象） - 特权提升操作（
ClusterRoleBinding 创建, RoleRef 修改） - Admission webhook 的
allow/deny 决策 - gRPC service method 实现
Sanitization（认证/授权屏障）：
- - Go HTTP 中间件（chi
Use(), gin Use(), echo middleware chain） - Kubernetes RBAC（
SubjectAccessReview, SelfSubjectAccessReview） - OPA/Gatekeeper 策略评估
- JWT 验证库（
golang-jwt/jwt/v5 的 Parse + WithValidMethods） - gRPC interceptor（
UnaryInterceptor, StreamInterceptor） - Rancher webhook 验证（
cattle.io webhook admission）
检测路径：
搜索认证/授权模式的 Grep 模式：
CODEBLOCK0
- 1. 搜索受保护的资源端点（HTTP handler、gRPC method、admission webhook handler）
- 检查是否有认证/授权中间件保护（middleware chain、interceptor、RBAC check）
- 验证屏障是否可被绕过：
- Admission webhook 在升级过程中是否被临时禁用？
- RBAC 策略是否存在跨 namespace 权限泄漏？
- JWT 验证是否检查了
alg 字段和
audience？
- OAuth state 参数是否正确验证？
- 中间件顺序是否正确（auth middleware 在路由之前）？
- Impersonation header 是否在 API proxy 中被正确过滤？
- ServiceAccount token 的权限范围是否过宽？
- 4. 若无屏障或屏障可被绕过 -> 标记为候选漏洞
Detection Checklist
- - [ ] Admission Webhook 升级期间绕过审计 (CWE-284)：Rancher/K8s webhook 在升级过程中是否被临时删除或跳过？升级脚本是否先删除 webhook 再安装新版本？
failurePolicy 设为 Ignore（failOpen）时 webhook 故障会导致请求被放行。namespaceSelector 配置不当可能导致特定 namespace 绕过 webhook 检查。务必验证 admission request 的来源（TLS 证书）防止伪造请求。 - [ ] 跨 Namespace 权限泄漏审计 (CWE-269)：Kyverno/OPA 策略中的
apiCall 是否使用了 ServiceAccount 的集群级权限访问其他 namespace 的资源？ - [ ] JWT 验证完整性审计 (CWE-287)：
jwt.Parse() 是否指定了 jwt.WithValidMethods([]string{"RS256"})？是否检查了 aud/iss/exp claims？ - [ ] OAuth state 参数验证审计 (CWE-287)：OAuth 回调处理是否验证
state 参数与 session 中存储的值一致？是否存在 token 交换时的 TOCTOU？ - [ ] gRPC Interceptor 认证审计 (CWE-285)：所有需要认证的 gRPC method 是否都经过
UnaryInterceptor 认证链？是否有 method 被排除在外？ - [ ] 中间件顺序审计 (CWE-285)：chi/gin/echo 的 auth 中间件是否在路由组注册之前执行？
r.Group().Use(authMiddleware) 是否覆盖了所有子路由？ - [ ] K8s Impersonation Header 过滤审计 (CWE-284)：API proxy 是否转发了
Impersonate-User/Impersonate-Group header？低权限用户是否能通过 proxy 冒充高权限用户？ - [ ] Rancher Cloud Credential 访问控制审计 (CWE-284)：Proxy API 是否正确验证用户对 cloud credential 的访问权限？是否存在通过代理绕过权限检查的路径？
- [ ] ServiceAccount Token 权限范围审计 (CWE-269)：自动创建的 SA token 是否具有集群级
cluster-admin 权限？是否遵循最小权限原则？
False Positive Exclusion Guide
以下模式不是此类漏洞：
- - 测试代码中的权限豁免 --
_test.go 文件中使用 fake.NewSimpleClientset() 跳过认证 - 健康检查端点无认证 --
/healthz、/readyz、/livez 不需要认证是正常行为 - 公开的 metrics 端点 --
/metrics 在 Prometheus 架构中通常不需要认证（需确认网络隔离） - 内部 gRPC 通信使用 mTLS -- 如果 gRPC 服务仅在 mesh 内通信且使用 mTLS，缺少 application-level 认证可接受
以下模式需要深入检查：
- -
admission.Allowed("") -- 空 reason 的 allow 决策可能是 webhook 的默认放行逻辑 if err != nil { return true } -- 认证错误时默认允许是高危模式- 中间件链中
Next() 在认证检查之前被调用 -- 可能导致后续 handler 在未认证情况下执行 ClusterRole 使用 * 通配符 -- resources: ["*"] + verbs: ["*"] 是过宽权限
Real-World Cases
详见 references/cases.md（7 个真实案例，需要时加载）。
Go Auth Bypass Vulnerability Patterns (CWE-287/863/269/284/285/862)
当审计 Go 代码中涉及认证流程、RBAC 权限检查、K8s admission webhook、JWT/OAuth 验证时加载此 Skill。
检测策略
通用检测模型，适用于 Go 云原生生态中认证/授权绕过的所有变体。
来源（攻击入口）：
- - HTTP 请求头部（Authorization, Impersonate-User, Impersonate-Group）
- Kubernetes API 请求（ServiceAccount token, RBAC RoleBinding）
- gRPC 元数据（authorization, 自定义认证头部）
- JWT/OAuth token（idtoken, accesstoken, state 参数）
- Webhook 回调请求（admission webhook, mutating webhook）
- Rancher API 代理请求（/v3/clusters/:id/proxy）
接收端（受保护资源/操作）：
- - Kubernetes API 调用（client-go 的 Create/Update/Delete）
- Rancher 管理 API（集群凭证、云凭证）
- Secret 读取/修改操作（v1.Secret 对象）
- 特权提升操作（ClusterRoleBinding 创建, RoleRef 修改）
- Admission webhook 的 allow/deny 决策
- gRPC service method 实现
净化（认证/授权屏障）：
- - Go HTTP 中间件（chi Use(), gin Use(), echo middleware chain）
- Kubernetes RBAC（SubjectAccessReview, SelfSubjectAccessReview）
- OPA/Gatekeeper 策略评估
- JWT 验证库（golang-jwt/jwt/v5 的 Parse + WithValidMethods）
- gRPC 拦截器（UnaryInterceptor, StreamInterceptor）
- Rancher webhook 验证（cattle.io webhook admission）
检测路径：
搜索认证/授权模式的 Grep 模式：
bash
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 代理 API
grep -rn proxy.
handler\|proxyRequest\|cloud.credential --include=*.go
K8s 模拟身份
grep -rn Impersonate\|impersonate\|as-user\|as-group --include=*.go
- 1. 搜索受保护的资源端点（HTTP handler、gRPC method、admission webhook handler）
- 检查是否有认证/授权中间件保护（middleware chain、interceptor、RBAC check）
- 验证屏障是否可被绕过：
- Admission webhook 在升级过程中是否被临时禁用？
- RBAC 策略是否存在跨命名空间权限泄漏？
- JWT 验证是否检查了 alg 字段和 audience？
- OAuth state 参数是否正确验证？
- 中间件顺序是否正确（auth middleware 在路由之前）？
- Impersonation header 是否在 API 代理中被正确过滤？
- ServiceAccount token 的权限范围是否过宽？
- 4. 若无屏障或屏障可被绕过 -> 标记为候选漏洞
检测清单
- - [ ] Admission Webhook 升级期间绕过审计 (CWE-284)：Rancher/K8s webhook 在升级过程中是否被临时删除或跳过？升级脚本是否先删除 webhook 再安装新版本？failurePolicy 设为 Ignore（failOpen）时 webhook 故障会导致请求被放行。namespaceSelector 配置不当可能导致特定命名空间绕过 webhook 检查。务必验证 admission request 的来源（TLS 证书）防止伪造请求。
- [ ] 跨命名空间权限泄漏审计 (CWE-269)：Kyverno/OPA 策略中的 apiCall 是否使用了 ServiceAccount 的集群级权限访问其他命名空间的资源？
- [ ] JWT 验证完整性审计 (CWE-287)：jwt.Parse() 是否指定了 jwt.WithValidMethods([]string{RS256})？是否检查了 aud/iss/exp claims？
- [ ] OAuth state 参数验证审计 (CWE-287)：OAuth 回调处理是否验证 state 参数与 session 中存储的值一致？是否存在 token 交换时的 TOCTOU？
- [ ] gRPC 拦截器认证审计 (CWE-285)：所有需要认证的 gRPC method 是否都经过 UnaryInterceptor 认证链？是否有 method 被排除在外？
- [ ] 中间件顺序审计 (CWE-285)：chi/gin/echo 的 auth 中间件是否在路由组注册之前执行？r.Group().Use(authMiddleware) 是否覆盖了所有子路由？
- [ ] K8s 模拟身份头部过滤审计 (CWE-284)：API 代理是否转发了 Impersonate-User/Impersonate-Group 头部？低权限用户是否能通过代理冒充高权限用户？
- [ ] Rancher 云凭证访问控制审计 (CWE-284)：代理 API 是否正确验证用户对云凭证的访问权限？是否存在通过代理绕过权限检查的路径？
- [ ] ServiceAccount Token 权限范围审计 (CWE-269)：自动创建的 SA token 是否具有集群级 cluster-admin 权限？是否遵循最小权限原则？
误报排除指南
以下模式不是此类漏洞：
- - 测试代码中的权限豁免 -- _test.go 文件中使用 fake.NewSimpleClientset() 跳过认证
- 健康检查端点无认证 -- /healthz、/readyz、/livez 不需要认证是正常行为
- 公开的 metrics 端点 -- /metrics 在 Prometheus 架构中通常不需要认证（需确认网络隔离）
- 内部 gRPC 通信使用 mTLS -- 如果 gRPC 服务仅在网格内通信且使用 mTLS，缺少应用层认证可接受
以下模式需要深入检查：
- - admission.Allowed() -- 空原因的 allow 决策可能是 webhook 的默认放行逻辑
- if err != nil { return true } -- 认证错误时默认允许是高危模式
- 中间件链中 Next() 在认证检查之前被调用 -- 可能导致后续 handler 在未认证情况下执行
- ClusterRole 使用 通配符 -- resources: [] + verbs: [*] 是过宽权限
真实案例
详见 references/cases.md（7 个真实案例，需要时加载）。
