用途：面向 gRPC 服务的安全排查流程，核心思路是抓住“服务本被视为内网、认证只在边缘代理做、后端信任任何可达调用方”这一类架构假设。适用于已获授权的目标排查。
主要能力按阶段划分： 一、指纹与端口发现。常见端口 50051、50052、443、9090、8080、8443、6565、9000 等；用 nmap -sV 探测开放端口，用 openssl s_client -alpn h2 确认 HTTP/2 协商，用带 content-type: application/grpc 的 HTTP/2 POST 观察返回头中是否出现 grpc-status 尾随头来判定是否为 gRPC 服务。 二、通过 reflection 枚举。安装 grpcurl（brew install grpcurl 或 go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest），用 grpcurl -plaintext 目标:50051 list 列出服务，再用 list、describe 查看方法与消息结构，可循环导出目录并筛选 admin、internal、debug 等关键字。 三、授权测试。用 -d '{}' 无认证调用敏感方法，遍历可枚举 id 字段做 IDOR 验证；判断依据是 gRPC 状态码：OK 且返回数据表示未授权执行成功；Unauthenticated(16)/PermissionDenied(7) 表示已有授权控制；Unimplemented(12) 表示路径或方法不存在；InvalidArgument(3) 表示已到达并解析输入。 四、信任边界绕过。测试伪造 JWT、代理注入身份头（如 x-user-id、x-tenant-id、x-envoy-internal 等）以及以 -bin 结尾的二进制元数据走私；关键验证是把伪造头分别直发后端端口和经公共代理发送，若代理原样转发则对真实用户可利用。 五、schema 发现。探测 proto、swagger.json、descriptor.pb 等路径，用 gh search code 查 proto 泄露，用 protoc --descriptor_set_out=bundle.bin --include_imports 重建描述符集，再用 grpcurl -protoset bundle.bin 驱动关闭 reflection 的目标。 六、gRPC-Web / grpc-gateway / Connect 转码路径。可用普通 HTTP/JSON 请求、手工构造长度前缀帧（1 字节标志 + 4 字节大端长度 + protobuf 负载，可用 protoscope 编码）或 grpc-web+json、Connect 协议方式调用内部方法。 七、HTTP/2 Rapid Reset（CVE-2023-44487）：需显式书面授权；h2load、ghz 是吞吐压测工具，不具备 rapid-reset 模式，不能用来验证该漏洞；更推荐通过服务端版本指纹对比已修复版本（如 nghttp2 >=1.57.0、Envoy、grpc-go 相应版本）来判断缓解缺口。
工具：grpcurl、grpcui、protoc、protoscope、buf；仅在授权测试中使用 secengjeff/rapidresetclient。
适用场景：对外暴露的 gRPC 服务、经代理转码的 REST/JSON 网关、内网微服务误暴露面。
限制与注意：reflection 开启本身只是设计选择，仅在暴露内部或管理方法时才作为问题；内网明文 gRPC 常见，仅在公网服务上算问题；gRPC-Web 代理与后端授权可能不同，需分别测试；protobuf 模糊测试导致 500 不等于可利用，需有 RCE 或数据泄露；DoS 类测试默认不在多数项目范围内，未获授权不得执行。资料未提供具体定价与平台支持信息。