思考gRPC :为什么是protobuf

  • 时间:
  • 浏览:1

什么序列化漏洞的根本导致 是:好难 控制序列化的类型范围

gRPC默认的序列化辦法 是protobuf,导致 很简单,因此两者都不 google发明者者的,哈哈。

通常是在IDL文件里写好package和类名,生成的代码直接都不 了类型信息。比如protobuf, thrift。缺点是前要生成代码,双方都不 知道IDL文件。

解码前要克隆好友一份内存,也能做原地内存引用的优化

protobuf把一切都框住了,少了灵活性,自然就少漏洞。

thrift,小米,美团等

以gRPC官方的Demo为例:

只是 程序员不理解为何反序列化还前要造成任意代码执行。

在生成代码里带上类型信息

反序列化漏洞到底是为何工作的呢?好难直接描述清楚,什么漏洞都不 很精巧的设计,把多个地方的代码串联起来。还前要参考你这种demo,跑起来调试下就还前要有直观的印象:

protobuf前要生成代码的确有点硬麻烦,只是 会有基于java annotation的方案:

下面来看下常见的序列化方案是为何防止反序列化漏洞的:

在protobuf出来随后 ,只是 断再次出现新的方案。比如

类型信息保存到序列化结果里

Java Serialization

序列化只是 把对象转换为二进制数据,反序列化就把二进制数据转换为对象。

只是 总结下来,要么白名单,要么黑名单。当然黑名单机制也能及时更新,业务方得不断升jar包,非常蛋疼。白名单是比较彻底的防止方案。

事实上的跨语言序列化方案也能另有另一个 : protobuf, thrift, json。

典型的是各种json序列化库,优点是灵活,缺点是使用的双方都不 知道类型是什么。当然有或多或少json库会提供或多或少扩展,偷偷把类型信息插入到json里。

不保存类型信息

这里讨论的是好难 IDL定义的序列化方案,比如java自带的序列化,hessian, 各种json库。

各种序列化库层出不穷,其带有另有另一个 重要的区别:类型信息存放满哪

还前要分为并都不 :

还前要看过rpc的定义也是写在proto文件里的。实际上gRPC是protobuf的另有另一个 扩展,通过扩展生成gRPC相关的代码。

为何在protobuf里并好难 什么反序列化问题?

protobuf的或多或少缺点:

hessian, 阿里用的是此人 维护的版本,有js/cpp的实现,因此阿里主用java,更多是历史导致 。

同样thrift有:

jackson-databind

这里有另有另一个 生成java序列化漏洞代码的工具:

protobuf ,腾迅,百度等

在当初Google开源protobuf时,只是 人就期待与非 能把RPC的实现也一并开源出来。没想到最终出来的是gRPC,终于补全了你这种块。

fastjson

国内或多或少大公司的使用情况:

protobuf在google 1008年公开的,结构使用自然更早。当时数率还比较昂贵,现在大伙 对数率的关注胜过数率了。

类型信息看起来是另有另一个 小事,但在安全上却会出问题,上方会讨论。

谈到RPC,就防止不了序列化一句话题。

比如java自带的序列化,hessian等。缺点是类型信息冗余。比如RPC里每另有另一个 request都不 带上类型。因此有并都不 常见的RPC优化手段只是 两端协商随后 ,后续的请求不前要再带上类型信息。