gRPC API风险解读

xxhzz

@PortalLab实验室

gRPC协议介绍

gRPC是Google发布的基于HTTP 2.0传输层协议承载的高性能开源软件框架，提供了支持多种编程语言的、对网络设备进行配置和纳管的方法。由于是开源框架，通信的双方可以进行二次开发，所以客户端和服务器端之间的通信会更加专注于业务层面的内容，减少了对由gRPC框架实现的底层通信的关注。如下图，DATA部分即业务层面内容，下面所有的信息都由gRPC进行封装。

gRPC交互过程如下图所示：

• 微服务：gRPC设计为低延迟和高吞吐量通信，gRPC非常适用于效率至关重要的轻型微服务。

• 点对点实时通信：gRPC对双向流媒体提供出色的支持，例如：移动端通讯。

• 多语言混合开发环境：gRPC工具支持所有流行的开发语言，使gRPC成为多语言开发环境的理想选择。

• 网络受限环境：使用Protobuf（一种轻量级消息格式）序列化gRPC消息，gRPC消息始终小于等效的JSON消息。

• 云原生应用：可以与Kubernetes、Istio等云原生技术结合使用，实现服务的发现、负载均衡、容错等功能，从而更好地支持云原生应用的开发和部署。

gRPC API特性

简单了解了gRPC协议的相关介绍和使用场景后，我们再来看看其存在的三大特性，这也是实现gRPC API自动化风险检测需要解决的三大难题。

在gRPC API之间相互通信的时候，其数据就是按照protobuf来进行序列化和反序列化的，而protobuf本身不是自描述的，必须依赖proto模板文件才能对gRPC序列化的数据进行解析。但是由于微服务本身可能部署在很多台机器上，每台机器提供的接口不同就会导致存在非常多的proto文件，部署的时候需要知道客户相应IP和port下对应的proto文件才行。所以如果想要获取到gRPC API通信的明文数据，就需要proto文件进行解析。

在没有proto文件还原数据的情况如何实现gRPC API自动化漏洞测试？

方法一：在存在相关源码或者原文件的情况下，可以通过相关手段来还原proto文件，包括逆向源代码，提取元信息，猜测数据结构等等方式。

方法二：如果是黑盒没有任何帮助性文件是可以通过还原数据类型进行Fuzz。这里具体可以参考蚂蚁安全实验室【Black Hat Asia 2021】中的议题中分享的方法-【基于字节码数据对Protobuf数据格式进行原始结构的还原】

通过递归解析的方法还原到数据类型，针对数据类型实现自动化漏洞Fuzz。

gRPC是基于HTTP/2协议的，HTTP/2本身是一个二进制协议。

HTTP/2 的 header 和 data 使用独立的 frame（其实就是帧，简单来说也是一种 Length-Prefixed 消息，是 HTTP/2 通信的基本单位） 发送，可以多次发送。

二进制帧

相对于HTTP 1.X的纯文本传输来，HTTP 2.0传输的是二进制数据，与Protocol Buffers相辅相成。使得传输数据体积小、负载低，保持更加紧凑和高效。

通信内容示例：

请求内容

HEADERS (flags = END_HEADERS) # header frame
:method = POST
:scheme = http
:path = /demo.hello.Greeter/SayHello
:authority = grpc.demo.com
content-type = application/grpc+proto

DATA (flags = END_STREAM) # data frame
<Length-Prefixed Message>

响应内容

HEADERS (flags = END_HEADERS) # header frame
:status = 200
content-type = application/grpc+proto

DATA # data frame
<Length-Prefixed Message>

HEADERS (flags = END_STREAM, END_HEADERS) # header frame
grpc-status = 0

gRPC本身提供了多种安全的功能，例如支持双向认证，要求客户端和服务端都验证对方的身份；支持TLS/SSL加密，用于在网络通信中实现端到端的加密传输等等。

通信类型	请求示例	响应示例
未加密的gRPC通信
TLS或mTLS加密的gRPC通信

从上图对比显示，如果客户gRPC API的通信流量采用了TLS等相关加密技术，那么它的请求和响应也需要再解密，这有点类似于HTTP和HTTPS，我们要实现gRPC的自动化风险检测就存在需要对相关加密解密的场景。

gRPC API安全风险

了解了gRPC API相关的特性之后，我们再来看看它到底存在什么样的安全风险。

默认情况下，gRPC API使用的是未加密的通信，这就意味着通信数据在传输过程中可能被窃听。如果gRPC API没有采用任何加密技术，那就可能会出现数据泄露、明文传输风险。

gRPC中使用的身份验证机制可能不安全，攻击者可以在没有身份验证的情况下尝试访问gRPC服务器上的API，这就可能导致gRPC API出现未授权、越权等安全风险。

gRPC服务器可能会受到服务拒绝攻击。当攻击者发送大量无效请求来占用服务器资源，可能导致拒绝服务攻击，当然这也是TCP协议的一个不足之处，很难从根源上解决问题。

在使用gRPC时，攻击者可能会介入通信并篡改数据，数据可能会泄漏到不正确的接收方，这可能会导致敏感数据泄露等安全问题，当然数据泄露的前提也是在没有采用任何加密方式的情况下导致的。

gRPC API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于0等。这类主要是由客户本身的业务逻辑上常出现的安全问题，例如：零元购、修改参数实现输入类逻辑漏洞。

总结

gRPC类型的API虽然本身提供了多种安全功能，但是如果相关开发人员由于疏忽或者错误配置，还是可能存在关于通信数据、认证授权、拒绝服务、业务逻辑等方面的安全风险。

关于Portal Lab

星阑科技 Portal Lab 致力于前沿安全技术研究及能力工具化。主要研究方向为数据流动安全、API 安全、应用安全、攻防对抗等领域。实验室成员研究成果曾发表于BlackHat、HITB、BlueHat、KCon、XCon等国内外知名安全会议，并多次发布开源安全工具。未来，Portal Lab将继续以开放创新的态度积极投入各类安全技术研究，持续为安全社区及企业级客户提供高质量技术输出。

原文始发于微信公众号（星阑实验室）：gRPC API风险解读