gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。目前提供 C、Java 和 Go 语言版本，分别是：grpc, grpc-java, grpc-go. 其中 C 版本支持C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持。

当前企业正在慢慢改用微服务架构来构建面向未来的应用程序，微服务使企业能够有效管理基础架构，轻松部署更新或改进，并帮助IT团队的创新和学习。它还可以帮助企业能够设计出可以轻松按需扩展的应用程序，此外，随着企业转换架构（从传统的单片式服务过渡到微服务），出现了在微服务之间进行有效通信的需求。客户端和服务器应用程序之间的这种关键而复杂的通信可以通过gRPC来处理，该框架促进了已连接系统之间的透明和高效的通信。尽管它很新（仅在2015年由Google开发），但它很快就获得了普及和采用。

在此文中，趋势科技将讨论开发人员在转向gRPC并在其项目中实现gRPC时可能面临的安全隐患。由于安全的gRPC API在整个应用程序安全中起着至关重要的作用，因此趋势科技提供了有关如何保护gRPC实施免受威胁并缓解风险的建议。

什么是gRPC？

gRPC可用于设计要求准确性、效率和语言独立性的新协议，因为它支持服务器和客户端的多种语言。这是一个云原生计算（CNCF）项目，并已被各大公司采用，例如流行的视频流网站Netflix，金融服务公司Square和平台即服务（PaaS）公司Docker。

将gRPC与其他RPC框架（例如SOAP和REST）进行了比较，尽管RESTful API被广泛使用，并且通常使用HTTP在应用程序或服务与JavaScript Object Notation（JSON）数据格式之间交换信息，但是它们具有性能和基于文本的方向限制。

许多组织已经将其API从REST迁移到gRPC，以利用更适合于服务间通信的gRPC二进制协议。默认情况下，gRPC使用HTTP / 2（基于二进制的协议）作为底层， HTTP / 2在一个TCP连接中支持多个流和请求，与其之前的HTTP / 1.0不同，HTTP / 1.0被设计为具有“单一请求，单一应答”方案。HTTP/1.1中的HTTP管道解决了这个问题，HTTP 2.0仍然具有更好的性能和更受支持。

HTTP / 1.0与HTTP / 2在请求和响应方面的不同之处

gRPC建立在协议缓冲区（或protobuf）之上，后者是Google的平台和语言无关的机制，用于序列化结构化数据。序列化是将内存中的对象转换为字节流的过程，可以轻松地将其保存到文件中或通过网络传输给其他应用程序。开发人员只描述一次数据接口，然后使用用于所选语言的协议缓冲区编译器对其进行编译。对于gRPC，协议缓冲区也用于定义RPC接口。

gRPC框架如何在在线零售应用程序中工作的图示，该产品具有通过API进行交互的产品和支付服务

发送字符串消息的gRPC“ HelloWorld”演示示例

gRPC的潜在威胁和风险

漏洞

gRPC支持多种编程语言，支持的语言中使用两种类型的实现：使用语言本身的实现，以及封装gRPC C-core编写的代码。这些封装程序可以将以不同支持的语言编写的调用转换为C调用。尽管C语言实现通常可以很好地执行，但由于需要实现更多功能以及内存管理功能，因此开发人员将漏洞引入系统的可能性更高。另一方面，使用诸如Java或Go之类的语言，这些语言已经实现了很多功能，并且还考虑了内存管理问题，这降低了开发人员向系统中引入严重影响的漏洞的机会。值得注意的是，选择合适的语言的重要性可能在保持系统更安全方面起着重要作用。

注意：1.可以使用纯C＃实现或围绕C的C＃封装程序；2.纯JavaScript实现以及与gRPC C-core的绑定（使用C ++附加组件）

不安全的数据传输通道和通道凭证

在远程过程调用期间，数据很可能会传输到目标服务器。这就是为什么开发人员应优先考虑为数据传输设置安全通道。这样做不仅可以防止数据泄漏，而且可以限制中间人（MiTM）攻击，因为熟练的攻击者可能会泄漏服务数据或向连接中注入恶意数据，这将干扰服务器。

数据泄漏可能会泄露有关你的服务或基础结构的实施详细信息，从而可能引发进一步的攻击，甚至导致服务或基础结构受到攻击。这是从不安全的gRPC调用捕获数据包的示例：

从不安全的gRPC调用捕获数据包的示例

gRPC在整个基础HTTP / 2协议以及各种身份验证机制上支持TLS，选择安全的实施是开发人员的责任。出于明显的原因，应避免使用诸如“InsecureChannelCredentials”之类的关键字进行复制和粘贴模式。

趋势科技已经执行Github.com代码搜索“InsecureChannelCredentials”关键字以及C ++语言限制（这是gRPC使用的常见限制）。搜索产生了超过11000个代码结果。趋势科技相信大量的搜索事件与演示和示例相关。但是，仍然有一些项目使用它们。

“InsecureChannelCredentials”代码搜索结果

程序执行漏洞

同样，对于AWS Lambda函数，最大的漏洞隐藏在实际的远程过程实现中。因为gRPC支持多种语言，所以趋势科技建议新手开发人员使用内存安全的语言，以避免严重影响内存管理的漏洞，如缓冲区溢出或导致远程代码执行(RCE)的UaF 漏洞。

但是，使用内存安全语言仍然无法缓解代码中可能出现的逻辑漏洞。为此，开发人员应为开发流程设置高标准，始终遵循安全软件开发最佳实践，并通过使用OWASP安全编码实践中的OWASP十大主动控制建议来实施主动控制。

即使在隔离的网络或私有云内部，也强烈建议对系统的关键部分使用集中式身份验证机制。在配置错误的情况下，环境内部的漏洞利用可能作为未授权访问的入口点，这可能严重干扰gRPC服务。

趋势科技还建议不要将gRPC身份验证详细信息硬编码或提交给供应链管理（SCM）系统，尤其是面向公众的系统。与其他任何凭据信息一样，这些凭据信息应存储在安全的位置，并且仅在需要时才进行访问。这是一个gRPC凭证泄漏的示例，趋势科技只是通过在GitHub上进行搜索而发现的：

在GitHub上找到的gRPC服务凭证示例

拒绝服务攻击

最后，我们想讨论趋势科技的拒绝服务（DoS）攻击发现。gRPC可以充当隔离环境中的“隐藏”消息服务，以及使用JSON格式的API替代面向公众的REST API服务。

在此，趋势科技想警告C / C ++ gRPC用户一个已知的但仍未修复的漏洞，该漏洞会在服务重新启动之前有效地拒绝服务调用。在短时间内打开大量连接时会触发该漏洞。实际上，这是由于Linux系统上打开的文件描述符的数量受到限制。

gRPC库的C / C ++实现内部的DoS攻击示例

根据我们的研究，当套接字连接在很短的时间内被打开，甚至在打开的套接字被关闭之后，这个漏洞就会被触发。趋势科技用Java和Go等非C语言封装的其他语言测试了此实现，发现它们不受此漏洞的影响。

趋势科技提出了以下变通办法，以帮助缓解在无法从一个平台切换到另一个平台的情况下发生DoS攻击的风险：

1.通过执行“sudo ulimit -n extendedNumber”来增加文件描述符的限制。

2.使用外部载荷平衡器和服务监视器可以减少单个实例的载荷并关注服务状态。

针对gRPC的安全建议

由于gRPC框架服务的可靠性和可伸缩性，使用该框架的企业数量不断增加，因此应该有更广泛的认识来保护该协议免受攻击风险和威胁。

尽管gRPC支持系统之间的高效通信，但必须强调的是，确保这些系统之间的通信安全是开发人员的责任。gRPC提供了有关受支持的身份验证机制的全面指南，该机制将与该协议一起使用，例如开发人员应遵循的使用SSL / TLS（具有或不具有基于Google令牌的身份验证）的协议。另外，开发人员还可以选择通过Credentials插件API插入自己的身份验证系统。

开发人员还应该使用能够验证内容的安全解决方案，以确保没有恶意负载能够通过从客户机到服务器的消息渗透到系统中，反之亦然。

对于企业来说，确保关键数据在传输过程中保持安全、密切关注服务状态并实施身份验证和授权以确保数据安全的解决方案也至关重要。

gRPC框架是开发人员和企业构建API，应用程序和微服务的有效工具。但是，像它的前任一样，它同样可以不受风险和威胁的侵害。因此，应该强调安全解决方案、检查和控制的必要性。

参考及来源：https://blog.trendmicro.com/trendlabs-security-intelligence/unsecure-grpc-implementations-compromise-apis-applications/