DEV Community: Expertos Tech

O que é gRPC - Como usar os Protocol Buffers | Parte 2

Expertos Tech — Tue, 26 Apr 2022 16:01:08 +0000

Autor: Rodrigo G. Tavares
Veja a Parte 1: O que é gRPC - Seus componentes RPC e HTTP2

Protocol Buffers ou para os íntimos Protobuf, é uma linguagem neutra criada para permitir a integração entre linguagens de programação, também usado como IDL pelo sistema gRPC.

Veremos nesse artigo o que são os Protocol Buffers, como eles funcionam e como eles se integram com o sistema gRPC.

Introdução

Quando falamos de integração entre linguagens, estamos trazendo o conceito de interoperabilidade, ou seja, a capacidade das aplicações e sistemas se comunicarem de maneira simples e fácil.

O que são os Protocol Buffers?

É uma linguagem neutra de plataforma neutra, usada para definição de tipos de dados e funções, muito parecido com o formato JSON, porém menor e mais rápido.

Como vimos no artigo anterior, ele é usado como IDL, linguagem para definição de interfaces, no sistema gRPC.

Por que eu preciso de uma linguagem neutra?
Uma linguagem neutra é uma linguagem simples, usada pra fazer a definição das interfaces e tipos usada nas integrações entre sistemas.

A partir dessa interface, cada linguagem que queira fazer uma integração deve interpretar o código escrito na IDL, gerando funções e tipos nos padrões da sua linguagem.

Essas interfaces geradas são chamadas de stubs e são usadas tanto pelo provedor de serviços, quanto pelo consumidor.

O lado provedor usará as interfaces para efetivamente implementar as regras daquele serviço, enquanto o consumidor, como o próprio nome diz, vai usá-las pra consumir, ou seja, acessar os serviços.
E é exatamente esse o papel dos protocol buffers.

Estrutura dos Protocol Buffers

Precisamos de atenção nos padrões e convenções de formatação do arquivo proto.

Mas por que isso é importante?
Usar o formato correto faz com que o processo de geração dos stubs siga as convenções de cada linguagem.
Em resumo, seguindo o padrão dos protocol buffers, fará com que o código gerado também esteja no padrão da linguagem de destino.

Configurações

Ao criar o arquivo protocol buffer, por convenção o nome do arquivo deve ser todo minúsculo com a extensão .proto.

Exemplo:

pessoa.proto
pessoafisica.proto
pessoajuridica.proto

Sintaxe

Uma vez criado o arquivo, devemos atribuir a versão da sintaxe, que pode ser: proto2 ou proto3.



syntax = "proto3";

Desse ponto em diante focaremos na versão de sintaxe proto3, que é a versão mais recente, para mais detalhes referente a versão proto2, há um link para a documentação nas referências do artigo.

Pacote

Agora precisamos definir o pacote, essa é uma instrução opcional usada pra compor o nome da mensagem, essa configuração deixa o nome único e evitando conflitos com outros tipos de nome semelhante, ou seja, podemos ter tipos de nomes iguais, desde de que estes estejam em pacotes diferentes.



package expertostech;

A instrução package em Java, go e csharp é usada pra compor o código gerado, no caso do csharp o valor é atribuído ao namespace, já no Go e no Java é atribuído em uma propriedade de mesmo nome.

Importação

Depois temos a área de importação, onde você pode fazer referência pra outros tipos, como é o caso da definição de data hora que precisa ser importado. Você também pode importar seus próprios tipos como referência.



import "google/protobuf/timestamp.proto";
import "endereco.proto";

Opções adicionais

Vamos agora para as configurações específicas de cada linguagem.

Para o Java, as configurações são:

java_multiple_files, se verdadeiro, indica que as classes serão geradas em arquivos separados.
java_outer_classname, o nome da classe para geração.



option java_multiple_files = true;
option java_outer_classname = "PessoaProtos";

Se você quiser organizar seus arquivos proto em pacotes diferentes das suas classes, você pode usar as seguintes configurações:

java_package, para o Java;
go_package, para o Go;
csharp_namespace, para o C#.

Essas três configurações sobrescrevem o valor do pacote, package ou namespace no c#, alterando os valores para geração das classes.



option java_package = "expertostech.tutorial.grpc";
option go_package = "expertostech/tutorial/grpc";
option csharp_namespace = "ExpertosTech.Tutorial.Grpc";

Definição de tipos

Uma curiosidade, é que os tipos nos protocol buffers são chamados de message, justamente por que esses tipos são usados como "mensagem" de envio e respostas nas suas integrações entre sistemas.

Mensagem

Iniciamos a declaração cada tipo com a palavra chave message, seguido do nome no padrão CamelCase.



message Pessoa {
}

É importante saber que podemos declarar várias mensagens em um mesmo arquivo proto.



message Pessoa {
}

message Usuario {
}

Atributos

Agora vamos declarar os atributos da mensagem.

Cada atributo começa com o tipo, seguido do nome e ao fim um código de identificação único.



message Pessoa {
  string documento_pessoal = 1;
}

Esse código deve ser único na mensagem e não no arquivo proto, isso quer dizer que você pode ter vários identificadores de atributo com o número 1, por exemplo, desde que eles estejam em mensagens diferentes.



message Pessoa {
  string documento_pessoal = 1;
}

message Usuario {
  string login = 1;
}

Essa identificação deve ser feita a partir do número 1 e pode chegar até 536.870.911, ou (2^29)-1.

Eu tenho minhas dúvidas se você vai precisar chegar tão longe, mas é importante dizer que os números entre 19.000 à 19.999 são reservados para a identificação dos atributos do framework, isso quer dizer que se você usá-los, a geração dos stubs apresentará erro.

Nos atributos usamos como convenção de nome, letras minúsculas separando cada palavra com um underscore.



message Pessoa {
  string documento_pessoal = 1;
  string nome = 2;
}

Tipos de dados

Na tabela abaixo podemos ver os principais tipos para declaração de atributos e quais são os seus correspondentes nas principais linguagens. Caso queira ver a lista completa, há um link para a documentação nas referências do artigo.

.proto Type	C++ Type	Java/Kotlin Type	C# Type	Go Type
string	string	String	string	string
int32	int32	int	int	int
float	float	float	float	float64
double	double	double	double	float32
bool	bool	boolean	bool	bool

Além dos tipos de dados da linguagem, você também pode usar como tipos nos seus atributos suas próprias mensagens, ou seja, você pode por exemplo criar uma mensagem Cidade e usá-la como referência dentro da mensagem Endereco.



message Endereco {
  string logradouro = 1;
  string numero = 2;
  string bairro = 3;
  Cidade cidade = 4;
}

message Cidade {
  string nome = 1;
  int32 ddd = 2;
}

É importante ressaltar que caso o tipo utilizado localizado em outro arquivo proto, é necessário importá-lo na seção import.



// ...
import "endereco.proto";
// ...
message Pessoa {
  string documento_pessoal = 1;
  string nome = 2;
  Endereco endereco = 3;
}

Listas de valores

Um recurso muito utilizado nas integrações são as listas de valores e temos dois tipos de listas nos protocol buffers:

Listas simples

Para declarar uma lista usamos a palavra chave repeated, seguida pelo tipo do campo e o nome da lista.
Por convenção, uma vez que as listas possuem diversos itens, elas sempre são nomeadas no plural.



message Pessoa {
  repeated Endereco enderecos = 3;
}

Listas chave e valor

Outra lista que temos disponível é a de chave e valor, chamada de map, nesse tipo de lista podemos definir um tipo de dado para chave e outro tipo de dado para valor, lembrando que tanto na chave quanto no valor podemos usar tipos da linguagem ou nossos próprios tipos.



message Pessoa {
  map<string, google.protobuf.Timestamp> atualizacoes = 4;
}

Enumerações

Fechando os principais tipos da linguagem, também temos um conjunto de valores fixos chamados de enum.
Os enums têm a estrutura semelhante a de uma mensagem, porém, ao invés de atributos, há uma lista fixa de valores.

Pra declarar uma enumeração usamos a palavra chave enum seguida do nome no padrão CamelCase.
Para a lista de valores, usamos as letras todas maiúsculas separando as palavras por um underscore.

Os itens do enum também precisam ser numerados, só que diferente dos atributos da mensagem, a lista de valores do enum deve iniciar no número 0.



enum TipoPessoa {
  NAO_DEFINIDA = 0;
  FISICA = 1;
  JURIDICA = 2;
}

Serviços

Fechamos a definição dos tipos, agora precisamos definir nossos serviços e funções.

Isso é muito simples, usamos a palavra chave service, seguida do nome do serviço no padrão CamelCase.



service PessoaServico {
}

Para declararmos uma função dentro do seu serviço, iniciamos com a palavra chave rpc, seguida pelo o nome da funcionalidade no padrão CamelCase, o parâmetro de entrada entre parênteses, seguido da palavra chave returns com a mensagem de retorno da função também entre parênteses.



service PessoaServico {
  rpc PessoaPorDocumento(Pessoa) returns (Pessoa) {}
}

Podemos declarar várias funções dentro de um mesmo serviço e obrigatoriamente todas elas precisam de uma mensagem como parâmetro de entrada e uma outra como parâmetro de saída.

Não podemos ter funções sem entrada ou saída, e os parâmetros devem obrigatoriamente ser mensagens e não tipos simples, como strings, inteiros e etc.



service PessoaServico {
  rpc PessoaPorDocumento(Pessoa) returns (Pessoa) {}
  rpc PessoaPorNome(Pessoa) returns (Pessoa) {}
}

Vejamos abaixo o código completo dos protocol buffers usados até aqui como exemplo.

Arquivo: endereco.proto



syntax = "proto3";
package expertostech;

option java_multiple_files = true;
option java_outer_classname = "EnderecoProtos";

option java_package = "expertostech.tutorial.grpc";
option go_package = "expertostech/tutorial/grpc";
option csharp_namespace = "ExpertosTech.Tutorial.Grpc";

message Endereco {
  string logradouro = 1;
  string numero = 2;
  string bairro = 3;
  Cidade cidade = 4;
}

message Cidade {
  string nome = 1;
  int32 ddd = 2;
}

Arquivo: pessoa.proto



syntax = "proto3";

package expertostech;

import "google/protobuf/timestamp.proto";

import "endereco.proto";

option java_multiple_files = true;

option java_outer_classname = "PessoaProtos";

option java_package = "expertostech.tutorial.grpc";

option go_package = "expertostech/tutorial/grpc";

option csharp_namespace = "ExpertosTech.Tutorial.Grpc";

service PessoaServico {

  rpc PessoaPorDocumento(Pessoa) returns (Pessoa) {}

  rpc PessoaPorNome(Pessoa) returns (Pessoa) {}

}

message Pessoa {

  string documento_pessoal = 1;

  string nome = 2;

  repeated Endereco enderecos = 3;

  map<string, google.protobuf.Timestamp> atualizacoes = 4;

  TipoPessoa tipo_pessoa = 5;

}

enum TipoPessoa {

  NAO_DEFINIDA = 0;

  FISICA = 1;

  JURIDICA = 2;

}

message Usuario {

  string login = 1;

  string senha = 2;

}

Gerando os stubs com Java

Para testar a geração veja o projeto completo no Github:
github/expertos-tech/protocol-buffer

Veja abaixo a estrutura do projeto e arquivo pom.xml.



<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

<span class="nt">&lt;groupId&gt;</span>expertostech<span class="nt">&lt;/groupId&gt;</span>
<span class="nt">&lt;artifactId&gt;</span>stub-gen<span class="nt">&lt;/artifactId&gt;</span>
<span class="nt">&lt;version&gt;</span>1.0-SNAPSHOT<span class="nt">&lt;/version&gt;</span>


<span class="nt">&lt;properties&gt;</span>
    <span class="nt">&lt;maven.compiler.source&gt;</span>17<span class="nt">&lt;/maven.compiler.source&gt;</span>
    <span class="nt">&lt;maven.compiler.target&gt;</span>17<span class="nt">&lt;/maven.compiler.target&gt;</span>
<span class="nt">&lt;/properties&gt;</span>

<span class="nt">&lt;dependencies&gt;</span>
    <span class="nt">&lt;dependency&gt;</span>
        <span class="nt">&lt;groupId&gt;</span>io.grpc<span class="nt">&lt;/groupId&gt;</span>
        <span class="nt">&lt;artifactId&gt;</span>grpc-stub<span class="nt">&lt;/artifactId&gt;</span>
        <span class="nt">&lt;version&gt;</span>1.45.1<span class="nt">&lt;/version&gt;</span>
    <span class="nt">&lt;/dependency&gt;</span>
    <span class="nt">&lt;dependency&gt;</span>
        <span class="nt">&lt;groupId&gt;</span>io.grpc<span class="nt">&lt;/groupId&gt;</span>
        <span class="nt">&lt;artifactId&gt;</span>grpc-protobuf<span class="nt">&lt;/artifactId&gt;</span>
        <span class="nt">&lt;version&gt;</span>1.45.1<span class="nt">&lt;/version&gt;</span>
    <span class="nt">&lt;/dependency&gt;</span>
    <span class="nt">&lt;dependency&gt;</span>
        <span class="nt">&lt;groupId&gt;</span>jakarta.annotation<span class="nt">&lt;/groupId&gt;</span>
        <span class="nt">&lt;artifactId&gt;</span>jakarta.annotation-api<span class="nt">&lt;/artifactId&gt;</span>
        <span class="nt">&lt;version&gt;</span>1.3.5<span class="nt">&lt;/version&gt;</span>
        <span class="nt">&lt;optional&gt;</span>true<span class="nt">&lt;/optional&gt;</span>
    <span class="nt">&lt;/dependency&gt;</span>
<span class="nt">&lt;/dependencies&gt;</span>

<span class="nt">&lt;build&gt;</span>
    <span class="nt">&lt;extensions&gt;</span>
        <span class="nt">&lt;extension&gt;</span>
            <span class="nt">&lt;groupId&gt;</span>kr.motd.maven<span class="nt">&lt;/groupId&gt;</span>
            <span class="nt">&lt;artifactId&gt;</span>os-maven-plugin<span class="nt">&lt;/artifactId&gt;</span>
            <span class="nt">&lt;version&gt;</span>1.4.1.Final<span class="nt">&lt;/version&gt;</span>
        <span class="nt">&lt;/extension&gt;</span>
    <span class="nt">&lt;/extensions&gt;</span>
    <span class="nt">&lt;plugins&gt;</span>
        <span class="nt">&lt;plugin&gt;</span>
            <span class="nt">&lt;groupId&gt;</span>org.xolstice.maven.plugins<span class="nt">&lt;/groupId&gt;</span>
            <span class="nt">&lt;artifactId&gt;</span>protobuf-maven-plugin<span class="nt">&lt;/artifactId&gt;</span>
            <span class="nt">&lt;version&gt;</span>0.6.1<span class="nt">&lt;/version&gt;</span>
            <span class="nt">&lt;configuration&gt;</span>
                <span class="nt">&lt;protocArtifact&gt;</span>com.google.protobuf:protoc:3.3.0:exe:${os.detected.classifier}<span class="nt">&lt;/protocArtifact&gt;</span>
                <span class="nt">&lt;pluginId&gt;</span>grpc-java<span class="nt">&lt;/pluginId&gt;</span>
                <span class="nt">&lt;pluginArtifact&gt;</span>io.grpc:protoc-gen-grpc-java:1.4.0:exe:${os.detected.classifier}<span class="nt">&lt;/pluginArtifact&gt;</span>
            <span class="nt">&lt;/configuration&gt;</span>
            <span class="nt">&lt;executions&gt;</span>
                <span class="nt">&lt;execution&gt;</span>
                    <span class="nt">&lt;goals&gt;</span>
                        <span class="nt">&lt;goal&gt;</span>compile<span class="nt">&lt;/goal&gt;</span>
                        <span class="nt">&lt;goal&gt;</span>compile-custom<span class="nt">&lt;/goal&gt;</span>
                    <span class="nt">&lt;/goals&gt;</span>
                <span class="nt">&lt;/execution&gt;</span>
            <span class="nt">&lt;/executions&gt;</span>
        <span class="nt">&lt;/plugin&gt;</span>
    <span class="nt">&lt;/plugins&gt;</span>
<span class="nt">&lt;/build&gt;</span>



</project>

O que vem a seguir?

Fechamos a definição dos protocol buffers, que é a parte central do sistema gRPC.
No próximo artigo, última parte dessa série, entraremos na parte prática de tudo que vimos até aqui, a implementação passo a passo de um serviço gRPC com Java, usando os protocol buffers.

E se você chegou até aqui, deixe o seu gostei no artigo e já aproveita pra seguir o canal ExpertosTech em todas redes sociais:
https://linktr.ee/expertostech

Referencias:

Documentação Prtocol Buffers

Vulnerabilidade do Spring e Java de março de 2022 | SpringShell ou Spring4Shell

Expertos Tech — Mon, 04 Apr 2022 15:44:23 +0000

Autor: Rodrigo Tavares

Introdução

Afinal de contas, o que é essa vulnerabilidade do Spring Framework com Java, divulgada na última quarta-feira dia 30 de março de 2022?

Também chamada de SpringShell ou Spring4Shell, a maior dúvida nesse momento é:

"Será que a minha aplicação está exposta e correndo risco de ataque"
"Será que meus dados ou dos meus clientes estão seguros?"

Então, pra saber tudo sobre essa vulnerabilidade e principalmente, como corrigir o problema, vem comigo até o final desse artigo que eu vou te mostrar.

Como foi relatada

Na última quarta-feira, 30 de março, alguns blogs apresentaram alguns prints de tela relatando uma possível vulnerabilidade no Spring Framework, o que eles chamaram de SpringShell.
Em alguns lugares chamavam de Spring4Shell, fazendo uma relação com uma vulnerabilidade parecida encontrada no Log4J recentemente conhecida como Log4JShell.

Print de uma PoC, proof of concept, postada no Twitter no dia 30 de março de 2022 demonstrando a vulnerabilidade

Segunda vez, mesmo problema

Um ponto interessante, é que essa mesma vulnerabilidade já havia sido tratada e corrigida em 2010, mas devido a uma nova funcionalidade do Java 9, foi possível explorar a vulnerabilidade de novo, vamos entender isso mais à frente.

No que consiste o problema

Para permitir a troca de dados entre cliente e aplicação o Spring converte dados das requisições HTTP em objetos e vice-versa.

Com o intuito de justamente evitar que um possível invasor tenha controle indevido à aplicação, container ou servidor usando funcionalidades internas desses objetos, o Spring Framework faz um tratamento especial protegendo acessos à objetos como Class, ClassLoader e ProtectionDomain, provavelmente ajustes feitos em 2010, na primeira ocorrência do problema.

Na atualização do Java 9, houve uma modificação do objeto Class, o que fez com que os tratamentos e validações implementadas pelo Spring Framework não fossem suficientes.

Classe CachedIntrospectionResults do Spring Framework, linha 288

PropertyDescriptor[] pds = this.beanInfo.getPropertyDescriptors();
for (PropertyDescriptor pd : pds) {
    if (Class.class == beanClass &&
            ("classLoader".equals(pd.getName()) ||  "protectionDomain".equals(pd.getName()))) {
        // Ignore Class.getClassLoader() and getProtectionDomain() methods - nobody needs to bind to those
        continue;
    }
    ...
}

Como é possível ver nesse trecho de código do Spring Framework, os métodos getClassLoader() e getProtectionDomain() não podem ser sobrescritos e ainda há um comentário que dizendo que eles foram ignorados por não haver necessidade de atribuir nada à neles.

// Ignore Class.getClassLoader() and getProtectionDomain() methods - nobody needs to bind to those

Resumindo, o objetivo da conversão das informações de uma requisição HTTP em objetos ou a serialização destes para texto é única e exclusivamente para troca de POJOs entre a aplicação e os clientes, controles à recursos do Java, servidores, bancos de dados e etc, devem ser explicitamente programados.

O que mudou no Java 9

O Java 9 introduziu o método getModule no objeto Class e isso permitiu a utilização do método getModule().getClassLoader().

Vale dizer que o simples acesso ao ClassLoader não é por si só uma vulnerabilidade, isso depende da forma que as funcionalidades dele foram implementadas.

Nesse caso específico, a vulnerabilidade está explorando a implementação da classe, WebAppClassLoaderBase do Tomcat 9.

Um ponto importante aqui é que o Java 9 foi lançado em 2017, ou seja, essa vulnerabilidade já vem sendo explorada por 5 anos até 2022, data de publicação desse artigo.

Passos para reprodução

Primeiro o invasor usa o ClassLoader das implementações de log pra criar um arquivo JSP malicioso.
Em seguida, o invasor escreve o código malicioso na página JSP.
E Pronto, agora é só fazer uma requisição pra página.

Esse tipo de acesso é chamado de RCE, Remote Code Execution, podemos dizer que é uma forma mais sofisticada do conhecido SQL Injection.

Vulnerabilidades como essa são registradas com um CVE, Common Vulnerabilities and Exposures, e aqui falamos de dois:

CVE-2022-22965: Justamente esse que foi exposto no dia 30 de março;
CVE-2010-1622:, solução da exposição do ClassLoader em 2010, antes do lançamento do Java 9.

Quem está vulnerável?

Agora que já vimos como funciona a vulnerabilidade vamos ver quem tá exposto.

Com os detalhes que vimos até agora, acredito você já tenha algumas pistas, segue abaixo todos os itens que você precisa validar:

Aplicação distribuída no formato war
- Lembrando que esse não é o formato de distribuição padrão
Utilizar JDK 9 ou superior
Ter no seu projeto a dependência spring-webmvc ou spring-webflux Usar as versões do Spring Framework 5.3.0 até a 5.3.17, 5.2.0 até a 5.2.19 ou versões mais antigas
- Para Spring Boot são as versões 2.6.5 e 2.5.11 ou versões anteriores
Usar o Apache Tomcat como container para servlets nas versões 10.0.19, 9.0.61 e 8.5.77 ou versões anteriores.

E lembrando que a vulnerabilidade não consiste em apenas um deles, você precisa atender todos para estar vulnerável.

Essa configuração são mais prováveis ao usar o Spring Framework para prover páginas JSP, não há dados da quantidade de sistemas e/ou aplicações afetadas, mas pelos padrões de programação atuais utilizando APIs Rest com páginas SPA ou aplicativos móveis, aparentemente vai afetar mais aplicações legadas.

A vulnerabilidade requer que haja um diretório para processar as páginas JSP ou para o deploy de arquivos War, pois é justamente onde serão criadas as páginas JSP para acesso como um backdoor.

O que fazer para resolver?

Abaixo estão opções para solução da vulnerabilidade, implementando apenas uma das opções abaixo sua aplicação estará segura.

Atualizar o Tomcat

Atualizar o Tomcat, com o patch de correção nas versões:

10.0.20;
9.0.62;
8.5.78.

ou qualquer versão superior à essas.

A vantagem de atualizar o Tomcat é justamente centralizar o ponto de correção, resolvendo diretamente o problema em todas as aplicações publicadas.

Atualizar o Spring Framework (ou Spring Boot)

Logo após a divulgação da vulnerabilidade, foi lançado um patch para correção do Spring Framework, sendo assim, basta atualizá-lo para a versão:

5.3.18;
5.2.20.

ou qualquer versão superior à essas.

Caso sua aplicação esteja usando Spring Boot atualize para as versões 2.6.6, 2.5.12 ou superior, que estão com suas referências atualizadas para uma das versões do Spring Framework citadas à cima.

Essa abordagem de atualização já é mais trabalhosa, uma vez que você precisará efetuá-la em todas as aplicações afetadas, então garanta que não esqueceu nenhuma.

De qualquer forma, mesmo que tenha atualizado o Tomcat, siga com a atualização das dependências do Spring Framework, evitando assim futuros problemas.

Downgrade do Java

Não sendo possível atualizar nem o Spring ou nem o Tomcat, outra possibilidade é fazer um downgrade do Java para a versão 8.

Realmente, pessoalmente é a que menos recomendo, principalmente se sua aplicação foi construída em versões posteriores, pois você pode ter comportamentos não esperados pela sua aplicação.

Desabilitar acesso à Class

Por fim, você pode desabilitar a atribuição de valores ao objeto Class com a instrução disallowedFields para o WebDataBinder de forma global, como pode ser visto no código abaixo.

@ControllerAdvice
@Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {

    @InitBinder
    public void setAllowedFields(WebDataBinder dataBinder) {
         String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
         dataBinder.setDisallowedFields(denylist);
    }

}

Aplicar globalmente vai funcionar, mas há uma brecha.
Se qualquer controller implementar seu próprio InitBinder, ele vai sobrescrever as configurações globais.

Sendo assim, para seguir essa estratégia de maneira mais segura, você precisa sobrescrever a classe RequestMappingHandlerAdapter na sua aplicação e atualizar WebDataBinder ao final de todas as outras inicializações.

Após a sobrescrição, na sua aplicação Spring Boot você declara um WebMvcRegistrations bean para Spring MVC ou um WebFluxRegistrations bean pra Spring WebFlux.

package expertostech;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.web.servlet.WebMvcRegistrations;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.ServletRequestDataBinder;
import org.springframework.web.context.request.NativeWebRequest;
import org.springframework.web.method.annotation.InitBinderDataBinderFactory;
import org.springframework.web.method.support.InvocableHandlerMethod;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter;
import org.springframework.web.servlet.mvc.method.annotation.ServletRequestDataBinderFactory;


@SpringBootApplication
public class MyApp {


    public static void main(String[] args) {
        SpringApplication.run(CarApp.class, args);
    }


    @Bean
    public WebMvcRegistrations mvcRegistrations() {
        return new WebMvcRegistrations() {
            @Override
            public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
                return new ExtendedRequestMappingHandlerAdapter();
            }
        };
    }


    private static class ExtendedRequestMappingHandlerAdapter extends RequestMappingHandlerAdapter {

        @Override
        protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> methods) {

            return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {

                @Override
                protected ServletRequestDataBinder createBinderInstance(
                        Object target, String name, NativeWebRequest request) throws Exception {

                    ServletRequestDataBinder binder = super.createBinderInstance(target, name, request);
                    String[] fields = binder.getDisallowedFields();
                    List<String> fieldList = new ArrayList<>(fields != null ? Arrays.asList(fields) : Collections.emptyList());
                    fieldList.addAll(Arrays.asList("class.*", "Class.*", "*.class.*", "*.Class.*"));
                    binder.setDisallowedFields(fieldList.toArray(new String[] {}));
                    return binder;
                }
            };
        }
    }
}

E para o Spring MVC sem o Spring Boot, a aplicação pode trocar de @EnableWebMvc e estender a classe DelegatingWebMvcConfiguration sobrescrevendo o método createRequestMappingHandlerAdapter, veja mais detalhes nas referências, configurações avançadas.

Conclusão

Corri aqui pra trazer esse conteúdo pra vocês o mais rápido possível.
Como vocês podem observar a vulnerabilidade é algo bem específico, e muito improvável colocar em risco aplicações mais novas.

Como esse é um assunto crítico, importante e sensível, vamos fazer esse conteúdo chegar ao máximo de pessoas possível, então compartilha esse artigo em todas as suas redes sociais, na empresa, seus projetos, com seus clientes, na sua faculdade, com seus professores, e tudo mais.

Não esquece de seguir o perfil Expertos Tech em todas as redes sociais: https://linktr.ee/expertostech

Referências:

Configurações Avançadas
- https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-config-advanced-java
Spring Framework
- https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
Oracle
- https://www.oracle.com/corporate/features/understanding-java-9-modules.html

O que é gRPC - Seus componentes RPC e HTTP2 | Parte 1

Expertos Tech — Sat, 26 Mar 2022 18:20:27 +0000

Autor: Rodrigo G. Tavares
Veja a Parte 2: O que é gRPC - Como usar os Protocol Buffers

Nem tudo são APIs Rest quando falamos de comunicação entre aplicações.

Introdução

Pensando em reduzir a latência e otimizar a comunicação nas aplicações atuais, o Google criou o sistema gRPC, que é uma implementação do modelo RPC.
No gRPC são usados proto buffers para definição das funcionalidades e a comunicação é feita usando o protocolo HTTP/2.

Nessa série de artigos veremos todos os detalhes do sistema gRPC: Seus principais componentes, funcionamento, pra que serve, onde e como usar.

Lembrando que essa aqui é só a primeira parte!
Nessa série além de vermos os detalhes do sistema gRPC, ao fim faremos uma implementação passo a passo, usando gRPC com Java e Spring Boot.

Componentes do gRPC

Antes de falarmos de gRPC, precisamos entender dois dos seus principais componentes.

Modelo RPC

O RPC, Remote Process Call, como o próprio nome diz, é uma padronização para execução de funcionalidades remotas simulando uma função local, ou seja, isso simplifica muito as integrações entre sistemas.

Também podemos dizer que na maioria dos casos, o RPC está relacionado à interoperabilidade, isso quer dizer que utilizando uma IDL, Interface Definition Language, podemos especificar uma ou mais funcionalidades detalhando seus tipos, parâmetros e retornos. Isso permite a interpretação dessas instruções por qualquer linguagem de programação.

Em resumo, o intuito da interoperabilidade é justamente garantir que programas escritos em linguagens de programação distintas possam se comunicar.

Padrão CORBA

Uma das mais antigas implementações de RPC é o CORBA, Common Object Request Broker Architecture, que simplificando, consiste na implementação de um módulo chamado ORB, responsável pela comunicação entre clientes e o servidores.

Java RMI

Em Java a implementação mais famosa do RPC é o RMI, sigla em inglês para Remote Method Invocation.

O RMI é a base do famoso Enterprise Java Beans, também conhecido como EJB.

Sua implementação requer a criação de stubs, que são um conjunto de interfaces que definem as assinaturas dos métodos, parâmetros e retornos.

Depois de criarmos os stubs, eles são implementados do lado do servidor e distribuídos em uma biblioteca para todos os clientes que invocarão os métodos remotos.

Uma informação interessante, é que no caso do RMI não há uma IDL para criação dos stubs, eles são escritos na própria linguagem, então isso quer dizer que o foco não é a interoperabilidade e sim a integração entre sistemas distribuídos feitos em Java mesmo.

SOAP

Por último e provavelmente a implementação RPC mais conhecida de todas, amplamente utilizada pelas mais diversas linguagens, vamos falar do modelo SOAP, Simple Object Access Protocol.

Exemplo de contrato WSDL da Nota Fiscal Eletrônica

Nesse modelo usamos o padrão WSDL, Web Services Description Language, que usando instruções por meio de tags e atributos XML, define o contrato do serviço.
Esse contrato é composto pelos tipos de dados, funcionalidades, parâmetros e retornos.

Para fazer a comunicação com os clientes, é usado protocolo http ou https, e pra acessar os métodos remotos no padrão SOAP, as linguagens fazem a interpretação do contrato WSDL, gerando as interfaces stubs com seus parâmetros para entrada e retorno.

Uma vez gerados, os stubs são distribuídos para os clientes que queiram invocar as funcionalidades SOAP remotas.

Agora que entendemos o que é RPC e vimos alguns exemplos, percebam que todas as implementações citadas acima precisam distribuir algum tipo de biblioteca para os clientes.
Guarda essa informação pois vamos precisar dela adiante.

Protocolo de comunicação

O gRPC utiliza o protocolo HTTP2 para comunicação, mas para entendermos melhor o motivo pelo qual precisamos dele, veremos os déficits do protocolo HTTP/1.x.

O que falta no HTTP/1.x

A definição do protocolo HTTP/1.x é muito simples e essa simplicidade tem um preço, que é redução do desempenho das aplicações.

A perda de desempenho acontece devido ao protocolo HTTP/1.x não ter compactação de dados e da impossibilidade de priorizar os recursos.

Normalmente são necessárias várias conexões simultâneas para completar uma requisição que atenda o negócio.

Lá no começo isso não fazia diferença nenhuma e o protocolo HTTP/1.x atendia muito bem os seus propósitos, só que hoje, a complexidade das aplicações modernas, precisando de cada vez mais recursos, contornar os problemas de latência é um grande desafio para os desenvolvedores.

O Protocolo HTTP2

O protocolo HTTP2 foi criado pelo Google e aprovado no início de 2015 pelo IESG, Grupo de Gestão de Engenharia para Internet, e ele é uma evolução de um protocolo experimental chamado SPDY, também criado pelo Google.

A primeira grande melhoria do protocolo HTTP2, é o formato dos dados transmitidos.

Enquanto o HTTP/1.x usa o formato de texto simples para comunicação, o protocolo HTTP2 usa um formato binário compactado e isso reduz drasticamente o tamanho da requisição e resposta.

Comunicação com HTTP2

A comunicação do protocolo HTTP2 é dividida em três partes:

Stream;
Mensagem;
Frame.

O Stream

Em uma mesma conexão TCP/IP podemos trafegar diversos streams e eles são bidirecionais, ou seja, por eles podemos tanto enviar mensagens como receber sem que seja necessário desconectar. Muito diferente do protocolo HTTP/1.x que só aceita uma requisição e uma resposta por conexão.

A Mensagem

É sequência completa de uma requisição e ela transita dentro do stream.

Como eu já mencionado anteriormente, o protocolo HTTP2 permite a troca de diversas mensagens dentro de um stream e essas mensagens são divididas em frames.

Os Frames

Por fim temos os frames, eles são a menor parte e compõem a mensagem. Nos frames temos informações dos cabeçalhos e os dados de requisição e resposta.

Recapitulando

Uma mesma conexão pode transferir vários streams;
Dentro de cada stream podemos ter várias mensagens;
Essas mensagens são divididas em frames;
Os frames transitam os dados efetivos da requisição.

Vimos até aqui, quais são os componentes de comunicação do protocolo HTTP2, agora veremos algumas vantagens de desempenho importantes que ele tem.

Múltiplas requisições

No protocolo HTTP/1.x, se quisermos fazer solicitações paralelas para minimizar a latência, é necessário efetuar várias conexões simultâneas.

Quando usamos os frames binários do protocolo HTTP2, temos o que chamamos de multiplexação completa de requisição e respostas, que basicamente é a capacidade do protocolo fazer requisições simultâneas, síncronas e assíncronas usando a mesma conexão.

Além disso também é possível alternar entre as requisições sem bloqueá-las.
Essa requisição elimina o custo de efetuar novas conexões e tudo isso permite a redução da latência geral, otimizando a utilização da rede.

Priorização de Stream

Outro avanço importante do protocolo HTTP2 é a possibilidade de alterar a prioridade dos streams.
Esse processo e feito atribuindo um número inteiro entre 1 e 256 a cada stream.

No protocolo HTTP2, você também pode atribuir uma dependência entre os Streams, ou seja, você poderia por exemplo dizer explicitamente que em uma requisição, a imagem B só será baixada depois da imagem A e isso sem a necessidade de efetuar uma nova conexão.

O que vem a seguir?

Pronto, agora que já entendemos os componentes base do sistema gRPC, podemos seguir para o próximo artigo onde veremos o funcionamento do Protocol Buffer, que é a linguagem usada pelo gRPC como IDL pra definição de funcionalidades, parâmetros e retornos.

Veja a Parte 2: O que é gRPC - Como usar os Protocol Buffers

E se você chegou até aqui, deixe o seu gostei no artigo e já aproveita pra seguir o canal ExpertosTech em todas redes sociais:
https://linktr.ee/expertostech

Referencias:

Wikipedia
- Chamada de procedimentos remotos
- CORBA
Google Developers
- Introdução a HTTP/2
Receita Federal
- Portal da nota fiscal eletrônica