gRPC API风险解读
2023-11-20 09:35:50 Author: 星阑实验室(查看原文) 阅读量:4 收藏


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自动化风险检测需要解决的三大难题。

ProtoBuf编码

这里简单介绍下,ProtoBuf是由 Google 设计的一种高效、轻量级的信息描述格式,它具有语言中立、平台中立、高效、可扩展等特性, 它非常适合用来做数据存储、RPC数据交换等

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

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

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

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

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

HTTP 2.0

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通信加密

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将继续以开放创新的态度积极投入各类安全技术研究,持续为安全社区及企业级客户提供高质量技术输出。


文章来源: http://mp.weixin.qq.com/s?__biz=Mzg3NDcwMDk3OA==&mid=2247484879&idx=1&sn=c9adfee1d264f809214698f2098b933a&chksm=cecd8c12f9ba050412618b72179d305d99750cd14582a19d5af10f0e4b49164f627d397a144d&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh