Nesta configuração, surgem dois tipos de conteúdo para a chave "animal": um apontando para a classe Dog e outro para a classe Cat. Portanto, são necessárias informações adicionais para saber qual classe deve ser usada no mapeamento.

Para resolver isso, o jackson-databind incorporou um processamento próprio que permite embutir o nome da classe a ser mapeada no JSON.
Por exemplo, como mostrado a seguir, o conteúdo da chave "animal" é transformado em um array, e o primeiro elemento especifica o nome da classe.```
{"animal":["Dog",{"name":"dog1","barkVolume":1.2}]}

Na saída do resultado, há uma linha `at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$1.run(TemplatesImpl.java:401)`.
Neste código de exemplo, uma NullPointerException está sendo lançada, mas pelo nome do método, pode-se perceber que algum processamento com efeitos colaterais está ocorrendo.

Para construir um JSON que realmente consiga executar o código, parece ser necessária uma investigação mais aprofundada.
Neste artigo, vamos nos limitar a esta introdução por enquanto, mas se artigos de investigação adicionais forem publicados em outros sites, gostaríamos de adicioná-los aqui.

A propósito, onde está implementada a lista negra crucial? É a seguinte classe:
* https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.8.9/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java#L51

Na verdade, parece que na versão 2.8.9 havia uma falha nesta lista negra. Esse problema é o CVE-2017-15095.

### Melhoria do CVE-2017-15095 que aprimorou a lista negra

Quanto à melhoria da falha na lista negra, primeiro, em https://github.com/FasterXML/jackson-databind/issues/1680, foi adicionado `s.add("com.sun.rowset.JdbcRowSetImpl");`.
Depois que o 2.9.0 foi lançado com isso, adicionalmente, em https://github.com/FasterXML/jackson-databind/issues/1737, a seguinte verificação de lista negra foi adicionada.```java
// [databind#1737]; JDK provided
s.add("java.util.logging.FileHandler");
s.add("java.rmi.server.UnicastRemoteObject");
// [databind#1737]; 3rd party
s.add("org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor");
s.add("org.springframework.beans.factory.config.PropertyPathFactoryBean");
s.add("com.mchange.v2.c3p0.JndiRefForwardingDataSource");
s.add("com.mchange.v2.c3p0.WrapperConnectionPoolDataSource");

Na versão anterior, o nome da classe `java.util.logging.FileHandler` escapava da verificação da lista negra e, ao ser instanciado, tentava abrir um arquivo. Na versão posterior, ele é capturado pela verificação da lista negra e uma exceção `JsonMappingException` é lançada.

A lista negra no momento da versão 2.8.10 ficou assim. O que começa com o comentário `[databind#1737]` é a lista negra adicional correspondente ao CVE-2017-15095.
* https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.8.10/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java#L52

### Sobre as condições de impacto da vulnerabilidade, a viabilidade do ataque e as contramedidas no lado da aplicação

Resumindo os resultados acima, as seguintes condições são necessárias para ser afetado pela vulnerabilidade do jackson-databind:
1. Estiver usando jackson-databind 2.8.9 / 2.9.0 ou inferior.
2. Para JSON obtido de fontes não confiáveis, estiver realizando um dos seguintes processamentos:
   * Chamar `ObjectMapper.enableDefaultTyping()` e depois desserializar.
   * Não chamar `ObjectMapper.enableDefaultTyping()`, mas usar a anotação `@JsonTypeInfo` na declaração da classe para permitir mapeamento e desserializar.
   * Mesmo que não seja usado no código da aplicação, o framework pode desserializar automaticamente em resposta ao cabeçalho da requisição `Accept` ou à extensão da URL.
3. O classpath contiver classes ("Gadgets") que podem ser exploradas na vulnerabilidade de serialização/desserialização Java.
4. Os campos de membro da classe Java de destino usarem tipos que podem aceitar classes Gadget, como o tipo `Object`.
   * Se o tipo for uma classe Bean específica da aplicação que não seja compatível com a classe usada no Gadget, é possível bloquear antes da criação da instância com um erro de verificação de tipo (a menos que a própria classe Bean específica da aplicação tenha uma vulnerabilidade de desserialização).

Se você realmente será afetado parece depender muito do uso/configuração do `ObjectMapper`, da combinação da anotação `@JsonTypeInfo`, e dos campos de membro da classe de destino, ou seja, do código da aplicação.

Além disso, se o nome da chave no JSON não existir na classe Java de destino, o Jackson simplesmente o ignora.
Portanto, para que o ataque seja bem-sucedido, é necessária uma personalização de acordo com o JSON de cada aplicação, e parece muito difícil criar um código de ataque que possa ser reutilizado em várias aplicações.

Além disso, sobre a condição 4, em uma escrita comum, acho que primeiro ninguém faria um campo de classe Java ser do tipo `Object`.
Acredito que, na maioria dos casos, as classes que permitem execução de código arbitrário também não são compatíveis com as classes Bean criadas pela aplicação.

Portanto, acredita-se que a possibilidade de ocorrer um ataque em larga escala ou de causar danos reais explorando essa vulnerabilidade (ou seja, o ataque ser bem-sucedido) é baixa.

Quanto às contramedidas no lado da aplicação, para a condição 3, como classes incluídas no JDK também podem ser exploradas, parece que, na prática, não é possível tomar medidas.
Portanto, a medida básica é atualizar o jackson-databind para a versão mais recente.
Se não for possível atualizar o jackson-databind para a versão mais recente, será necessário remover a chamada `ObjectMapper.enableDefaultTyping()` ou a anotação `@JsonTypeInfo` e reformular o design para não depender disso. Por exemplo, criar um serializador personalizado.

No entanto, se você já estiver usando como uma API chamável remotamente, não pode simplesmente alterar o formato JSON.
Parece que, dependendo da configuração da anotação `@JsonTypeInfo`, é possível aceitar apenas nomes de classes previstos pelo programador, limitando as subclasses, etc.
Consulte a documentação abaixo para mais detalhes.
* JacksonPolymorphicDeserialization
  * https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

#### Sobre os prós e contras da contramedida de lista negra e a criação de um desserializador personalizado

O jackson-databind 2.8.10 / 2.9.1 respondeu ao CVE-2017-7525 e CVE-2017-15095 com a contramedida de lista negra.
No entanto, como é evidente nos problemas relacionados ao OGNL do Struts2, a contramedida de lista negra não é infalível.
(Na opinião pessoal do autor, acho que é uma medida com alguma eficácia para o nível dos chamados "script kiddies" que apenas aplicam ferramentas de varredura.)

Portanto, se você realmente deseja uma contramedida fundamental, o autor acredita que é importante desabilitar/não usar funcionalidades que incorporam informações de classe no JSON, como `ObjectMapper.enableDefaultTyping()`.
Então, como resolver o problema que `ObjectMapper.enableDefaultTyping()` estava tentando resolver?

Sobre isso, o próprio autor não tem uma alternativa que possa ser considerada a resposta correta.
A raiz do problema é, na minha opinião, "poder mapear quando a classe Java de destino é ambígua, sem depender de JSON não confiável".
Uma abordagem que pode tornar isso possível, o autor acredita, é criar um desserializador personalizado.
Um desserializador personalizado permite receber JSON durante a desserialização no lado do código do programa e controlar o objeto gerado por conta própria.

Por exemplo, se chegar `{"animal":{"name":"dog1","barkVolume":1.2}}`, é possível decidir no programa: "Como há a chave `barkVolume`, isso será instanciado como classe Dog".
Se chegar `{"animal":{"name":"cat1","likesCream":true,"lives":10}}`, é possível decidir no programa: "Como há as chaves `likesCream` e `lives`, isso será instanciado como classe Cat".
Usando isso, não é mais necessário incorporar o nome da classe no JSON.

Pessoalmente, tive a impressão de que o formato JSON com nomes de classe incorporados prejudica a interoperabilidade com outras linguagens/bibliotecas (se houver algo que permita extensões semelhantes em outras linguagens ou bibliotecas, por favor, me avise).
Em um cenário de interoperabilidade com outros sistemas, parece mais adequado criar um desserializador personalizado no lado do Jackson do que fazer com que os outros incorporem nomes de classe exclusivos para atender às necessidades do Jackson.

Acredito que existam outras soluções, e ficaria grato se os leitores pudessem compartilhar suas opiniões sobre "também existe esta solução".
(Um exemplo extremo seria não mapear para classes individuais e desserializar tudo no formato `Map<String, Object>` ou `List<String, Object>`.)

Encontrei alguns artigos de referência para criar um desserializador personalizado, então vou colocar links, embora sejam em inglês.
* Jackson: create a custom JSON deserializer with StdDeserializer and JsonToken classes | Dede Blog
  * http://www.davismol.net/2015/05/20/jackson-create-a-custom-json-deserializer-with-stddeserializer-and-jsontoken-classes/
* Getting Started with Deserialization in Jackson | Baeldung
  * http://www.baeldung.com/jackson-deserialization
* Custom JSON Deserialization with Jackson - DZone Integration
  * https://dzone.com/articles/custom-json-deserialization-with-jackson
* Building a Custom Jackson Deserializer - The Boy Wonders
  * http://www.robinhowlett.com/blog/2015/01/01/building-a-custom-jackson-deserializer/

JavaDoc do jackson-databind (versões 2.8 e 2.9):
* https://fasterxml.github.io/jackson-databind/javadoc/2.8/
* https://fasterxml.github.io/jackson-databind/javadoc/2.9/

O autor também criou um código de exemplo de desserializador personalizado, espero que sirva como dica.
* [custom-deserializer-demo.groovy](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/blob/master/custom-deserializer-demo.groovy)

## Sobre o S2-055

Até aqui, vimos vulnerabilidades do próprio Jackson. Agora, como isso afeta o plugin REST do Struts2? Verificamos usando o struts2-rest-showcase que acompanha o Struts2.

O uso do plugin REST do Struts foi baseado no seguinte:
* http://struts.apache.org/plugins/rest/

### O plugin REST do Struts2 não chama ObjectMapper.enableDefaultTyping()

A propósito, as condições para ser realmente vulnerável no CVE-2017-7525 eram as seguintes:
* Para JSON obtido de fontes não confiáveis, estiver realizando um dos seguintes processamentos:
  * Chamar `ObjectMapper.enableDefaultTyping()` e depois desserializar.
  * Não chamar `ObjectMapper.enableDefaultTyping()`, mas usar a anotação `@JsonTypeInfo` na declaração da classe para permitir mapeamento e desserializar.

Verificamos se o plugin REST do Struts2 contém código que se enquadra nessas condições e confirmamos que nenhuma delas está incluída.
Na verdade, nem `ObjectMapper.enableDefaultTyping()` nem `@JsonTypeInfo` são usados no plugin REST, e nem mesmo em toda a árvore de fontes do Struts2, mesmo na versão 2.5.14 anterior à correção.
* https://github.com/apache/struts/tree/STRUTS_2_5_14

Na árvore de fontes completa do Struts2, a única classe que usa o ObjectMapper do Jackson é `org.apache.struts2.rest.handler.JacksonLibHandler`. Após verificar o código-fonte, confirmamos que na versão 2.5.14 de fato não usa `ObjectMapper.enableDefaultTyping()`.
* https://github.com/apache/struts/blob/STRUTS_2_5_14/plugins/rest/src/main/java/org/apache/struts2/rest/handler/JacksonLibHandler.java
  * Este arquivo Java não mudou de conteúdo na versão 2.5.14.1.

Portanto, acredita-se que o próprio plugin REST não apresentava problemas em relação ao CVE-2017-7525 mesmo na versão 2.5.14.
A vulnerabilidade ocorre quando a anotação `@JsonTypeInfo` é definida no campo da classe que mapeia o JSON no lado da aplicação.
Assim, na verificação usando struts2-rest-showcase abaixo, definimos `@JsonTypeInfo` no campo de destino do mapeamento adicionado no lado da aplicação e verificamos.

Aliás, parece que o Struts2 também tem um plugin JSON.
* http://struts.apache.org/plugins/json/
* Olhando o código-fonte do plugin JSON, o pom.xml não inclui nenhuma outra biblioteca JSON como dependência.
* Parece que ele implementa o processamento JSON por conta própria.
* https://github.com/apache/struts/tree/STRUTS_2_5_14/plugins/json
* Portanto, acredita-se que a vulnerabilidade do jackson-databind não afeta o plugin JSON.

### Tornando o struts2-rest-showcase compatível com Jackson

O struts2-rest-showcase é um exemplo que implementa CRUD da classe Order usando o plugin REST. Adicionaremos a ele as classes Zoo / Animal / Cat / Dog usadas no código de exemplo da vulnerabilidade do Jackson, e um ZooController para processar o CRUD em JSON.

O código-fonte completo pode ser verificado abaixo (verificamos a construção e execução com JDK8 neste artigo).
* [rest-showcase](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/tree/master/rest-showcase)

Principais modificações:
* Porta de escuta pelo jetty-maven-plugin alterada para 18088. (`mvn jetty:run`)
* Adicionadas dependências jackson-core e jackson-databind.
* Adicionadas classes Zoo, Animal (abstract), Dog, Cat. Adicionada classe ZooService como camada de serviço.
* Adicionado ZooController com CRUD mínimo (JSP de visualização omitido).
* No struts.xml, o handler para JSON foi alterado para JacksonLibHandler.
* Incorporado maven-wrapper para que, com apenas o JDK instalado, seja possível construir e executar diretamente com mvnw / mvnw.bat.

Construção e execução:
1. Após clonar o repositório, vá para o diretório rest-showcase e execute `mvnw jetty:run`. (Atenção: na primeira execução, o download do maven ocorrerá, podendo levar alguns minutos ou até mais de 10 minutos dependendo do caso.)
1. Acesse http://localhost:18088/struts2-rest-showcase/ e, se a lista de Orders for exibida, é sucesso.
1. Para encerrar a execução, pressione Ctrl-C.
1. Se modificar arquivos Java, encerre com Ctrl-C e execute `mvnw jetty:run` novamente.

Verificação com o comando curl: (assumindo que passa pelo proxy local localhost:8080 como proxy http)```
一覧取得:
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo"

ID指定:
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo/1"
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo/2"

削除:
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo/2" -X DELETE

Aqui, vamos enviar uma requisição JSON usando o método POST e chamar o método ZooController.create().```
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo" -X POST -H "Content-Type: application/json" -d '{"id":"3","animal":{"name":"dog2","barkVolume":2.3}}'

Portanto, descomente o `@JsonTypeInfo` do campo `animal` para ativá-lo. Pare a aplicação web com Ctrl-C e execute `mvnw jetty:run` novamente.```java
// 次のimportを忘れずに追加
import com.fasterxml.jackson.annotation.JsonTypeInfo;
//...
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    public Animal animal;
    //public Object animal;

→ `HTTP/1.1 201 Created` é retornado. Ao listar, podemos confirmar que foi adicionado.

### Verificando CVE-2017-7525 no Struts2 REST plugin 2.5.14

No pom.xml do repositório, o artifact struts do `<parent>` especifica a versão 2.5.14, portanto, por padrão, é vulnerável ao CVE-2017-7525.
Para verificar, execute o seguinte comando curl. O nome da classe e seu conteúdo são baseados em cve-2017-7525-check.groovy, portanto, se a mesma resposta do jackson-databind 2.8.8 for retornada, considera-se vulnerável.```
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo" -X POST -H "Content-Type: application/json" -d '{"id":"3","animal":["com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",{"transletBytecodes":["AAIAZQ=="],"transletName":"a.b","outputProperties":{}}]}'

O tipo do campo `animal` é a classe `Animal`, que não é um subtipo da classe `com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl`, então parece que foi lançada uma `IllegalArgumentException`.

Bem, vamos corrigir o campo `animal` em `Zoo.java` para o tipo `Object` e executar novamente com `mvnw jetty:run`.```java
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    //public Animal animal;
    public Object animal;

Este é o mesmo caso de exceção vulnerável verificado com cve-2017-7525-check.groovy.

A partir disso, confirmamos a existência da vulnerabilidade CVE-2017-7525 no jackson-databind no Struts2 REST plugin 2.5.14.

Também descobrimos que é necessário usar o tipo Object além de `@JsonTypeInfo`.

Abaixo está uma opinião pessoal do autor, mas acredito que não seja comum especificar a classe Object ou classes compatíveis com gadgets de vulnerabilidade de desserialização Java como tipo de campo em classes de dados ao criar APIs REST. Portanto, sinto que seria difícil obter sucesso real em um ataque.

### Confirmando a correção no Struts2 REST plugin 2.5.14.1

Vamos verificar se a vulnerabilidade foi corrigida na versão 2.5.14.1.

Altere a versão do artefato `<parent>` no pom.xml para 2.5.14.1, reinicie com `mvnw jetty:run` e execute o mesmo comando curl de antes.```
curl -v -x localhost:8080 -H "Accept: application/json" "http://localhost:18088/struts2-rest-showcase/zoo" -X POST -H "Content-Type: application/json" -d '{"id":"3","animal":["com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",{"transletBytecodes":["AAIAZQ=="],"transletName":"a.b","outputProperties":{}}]}'

Esta é a mesma exceção após a correção da vulnerabilidade, como verificada no cve-2017-7525-check.groovy.

Ao abrir com uma IDE que suporta Maven, como Eclipse, e verificar a versão do jackson-databind após a resolução das dependências, você poderá confirmar que é realmente 2.9.2. Se não tiver uma IDE, você pode usar `mvnw help:effective-pom` para gerar o pom final e pesquisar por jackson-databind para confirmar que está usando a versão 2.9.2.

Sobre o CVE-2017-15095, omitirei, mas com base no exposto, foi confirmado que a versão 2.5.14.1 corrigiu a vulnerabilidade do jackson-databind.

### PoC do S2-055

※ Adicionado em 2017-12-08

Um artigo de pesquisa e relatório de PoC sobre o S2-055 foi publicado.
* Análise e Configuração do Ambiente da Vulnerabilidade S2-055 | Blog da NSFOCUS
  * http://blog.nsfocus.net/s2-055/

Ao ler com a ajuda do Google Tradutor, parece que há o mesmo entendimento sobre as condições de ocorrência e a viabilidade do ataque.

Na verdade, foi mostrado um PoC que modificou o rest-showcase e o HTTP communication que iniciou a calculadora.

Peguei apenas a parte JSON e primeiro testei com Jackson sozinho, que é o seguinte código de amostra.
* [cve-2017-7525-poc.groovy](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/blob/master/cve-2017-7525-poc.groovy)

Ao executar especificando a versão 2.8.8 aqui, no ambiente do autor foi gerada a seguinte saída.```
your jackson version MAY NOT BE SAFE to CVE-2017-7525
(...)
Caused by: java.lang.NullPointerException
        at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$1.run(TemplatesImpl.java:401)
(...)

ここで、同月中にblack-list対策の追加修正として 2.9.0 がリリース。
* https://github.com/FasterXML/jackson-databind/issues/1680

これが追加された：```java
s.add("com.sun.rowset.JdbcRowSetImpl");

### 2017-08

* Lançado 2.8.10 com suporte para #1680, #1737.
* Também em agosto, a seguinte issue foi aberta, e a resposta abrangente como CVE-2017-7525 está sendo discutida.
  * https://github.com/FasterXML/jackson-databind/issues/1723
* No blog de Adam Caudill, uma explicação do exploit para CVE-2017-7525 foi publicada.
  * https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/

### 2017-09

* Lançado 2.9.1 com suporte para #1737.

### 2017-10

No bugzilla a seguir, a correção do CVE-2017-7525 nas versões 2.8.9 / 2.9.0 foi considerada insuficiente, e o trabalho para aplicar a blacklist mais recente do 2.8.10 / 2.9.1 como novo CVE-2017-15095 começou.
* https://bugzilla.redhat.com/show_bug.cgi?id=1506612

### 2017-11

* Informações sobre CVE-2017-15095 foram divulgadas pela RedHat.
  * https://access.redhat.com/security/cve/cve-2017-15095

* Na issue do jackson-databind, houve uma troca de perguntas e respostas sobre o status da resposta ao CVE-2017-15095.
  * https://github.com/FasterXML/jackson-databind/issues/1847
  * Foi respondido que o suporte foi feito nas versões 2.8.10 / 2.9.1.

### 2017-12

* Um artigo explicativo foi publicado no blog do desenvolvedor do WAF Scutum na nuvem.
  * https://www.scutum.jp/information/waf_tech_blog/2017/12/waf-blog-052.html
  * Neste artigo, é mencionado que na blacklist do 2.9.3 há uma deficiência na classe do Spring, o que não é um problema emergencial, mas pode haver uma atualização futura.
  * Também é discutido se a responsabilidade por essa vulnerabilidade era realmente da biblioteca ou da aplicação.

## Sobre as tendências futuras de vulnerabilidades relacionadas a serialize/deserialize em Java

Tenho a impressão de que as informações sobre vulnerabilidades relacionadas a serialize/deserialize em Java aumentaram desde o ano retrasado até o ano passado.
Como exemplo, as informações de vulnerabilidade dos produtos Pivotal, incluindo Spring, são divulgadas em https://pivotal.io/security/, e de fato, em 2017, além do CVE-2017-4995, as seguintes informações de vulnerabilidade foram divulgadas.

* https://pivotal.io/security/cve-2017-8045
  * RCE devido a problema de desserialização de `org.springframework.amqp.core.Message` no Spring AMQP
* https://pivotal.io/security/cve-2017-8046
  * RCE devido a falha no tratamento de JSON no método PATCH do Spring Data REST

Por ser uma vulnerabilidade que facilmente leva a RCE, acredita-se que tanto atacantes quanto pesquisadores de vulnerabilidades estejam prestando atenção ao serialize/deserialize em Java.
Acredito que nos próximos anos continuarão a surgir relatos de vulnerabilidades relacionadas ao processo de serialize/deserialize.
No entanto, embora o Jackson também seja assim, na realidade, em muitos ambientes de desenvolvimento atuais, onde a eficiência do desenvolvimento é aumentada e a troca de dados via APIs remotas se tornou comum, é praticamente impossível não usar serialize/deserialize ou criá-los do zero.
O importante, na minha opinião pessoal, é criar uma cultura e um ambiente de desenvolvimento ágeis, que permitam atualizar as bibliotecas o mais rápido possível quando uma vulnerabilidade for divulgada.

Como tenho sentimentos sobre como lidar com vulnerabilidades em middleware, bibliotecas e frameworks dos quais dependemos, escrevi o seguinte como reflexão.

## Reflexão

Quando vi as informações de que S2-054, 055 foram divulgadas e que a vulnerabilidade do Jackson as afetava, fiquei bastante chocado.
Isso porque, alguns dias antes, um colega me perguntou: "Qual biblioteca você recomenda para parsear JSON em Java?" e eu respondi com ar de sabedoria: "O Jackson é amplamente usado em OSS e tem um histórico comprovado; se você pesquisar, encontrará muitos artigos e Q&As, então recomendo."

Eu mesmo usava o Jackson em ferramentas internas da empresa e o achava prático.
No entanto, naquela época, eu não tinha conhecimento do CVE-2017-7525 e estava confiante de que o Jackson, por ser amplamente usado em OSS e por muitos usuários, era seguro.

Foi então que outro colega encontrou o blog de Adam Caudill e me informou sobre a existência do CVE-2017-7525. Poucos dias depois de eu ter recomendado o Jackson com ar de sabedoria, uma vulnerabilidade do Jackson levou a uma atualização do Struts2, e a vulnerabilidade do Jackson em si já havia sido tratada meses antes. Como engenheiro na área de segurança, não teria como negar que negligenciei a coleta de informações sobre vulnerabilidades da biblioteca que eu mesmo usava (na verdade, só posso dizer que foi exatamente isso).

Portanto, meu estado mental nos últimos dias estava péssimo (aumento de pressão arterial e pulso, mãos trêmulas, lágrimas querendo sair mesmo sem tristeza, palpitações incessantes, etc.). Para lidar com isso, decidi primeiro entender o que era o CVE-2017-7525 e qual era a situação do Jackson, e dediquei o fim de semana para pesquisar e escrever este artigo.

Refletindo sobre isso, sinto profundamente que, quando se está focado no desenvolvimento, é realmente difícil prestar atenção às informações de atualização das bibliotecas dependentes.
Em meio a tarefas de desenvolvimento que surgem uma após a outra, é praticamente impossível investigar completamente todas as funcionalidades e aspectos de qualidade, como vulnerabilidades, de todas as bibliotecas usadas.
Por outro lado, as funcionalidades exigidas no desenvolvimento são cada vez maiores, e criar tudo do zero também é praticamente impossível.
Em algum momento, é preciso "confiar" nas bibliotecas usadas para tornar o desenvolvimento mais eficiente.
No entanto, monitorar todas as informações de atualização das ferramentas e bibliotecas usadas no desenvolvimento diário e verificar se há correções de segurança também é extremamente difícil.
Claro, reconheço que atualmente existem serviços que, ao cadastrar as ferramentas e bibliotecas utilizadas, distribuem informações de atualização para resolver esse problema.

O que percebi com a piora do meu estado mental foi que tenho um forte "sentimento de autocobrança e culpa por não ter feito algo".
Eu estava me rotulando negativamente: "Sou engenheiro de segurança e não estava ciente das informações de vulnerabilidade da biblioteca que eu mesmo usava..."
Mesmo para desenvolvedores comuns que não estão envolvidos na indústria de segurança,
muitos podem estar carregando arrependimentos e ansiedades como "Se eu não tivesse sugerido o Struts2 naquela época..." ou "Preciso gerenciar melhor o ciclo de vida das bibliotecas/frameworks (= estou preocupado comigo mesmo/a situação atual em que não consigo fazer isso)".

Se tentássemos "resolver" esses problemas de frente, teríamos que coletar informações de vulnerabilidade uma a uma, verificar o código-fonte e as funcionalidades de cada biblioteca ou framework que pretendemos usar, investigar minuciosamente se são padrões de fato e, após o início da operação, gerenciar rigorosamente o ciclo de vida.

No entanto, será que essa abordagem de "bater na pedra antes de atravessar a ponte" é realmente possível nos diversos ambientes de desenvolvimento atuais?

Ao escrever este artigo, pensei que a era de tratar "o que não foi feito / o que não foi possível fazer / o que não foi percebido" como causa ou culpado, e eliminá-lo = "torná-lo possível" como a única "solução do problema" já acabou.
Nessa cultura, a menos que se seja uma pessoa perfeita, o desenvolvedor terá que lidar eternamente com seu "não feito, não possível, não percebido".
Como não existem pessoas perfeitas, acho que só pessoas com uma mente muito forte conseguiriam suportar isso.

Em problemas de segurança de software, o verdadeiro causador do dano é o atacante. Quem torna a situação negativa é o atacante que explora a vulnerabilidade.

A grande maioria dos desenvolvedores, em princípio, trabalha com boa vontade e seriedade no desenvolvimento. Já nesse ponto, a situação é positiva.
"Não gerenciar o ciclo de vida das bibliotecas/frameworks" ou "não coletar/monitorar informações de vulnerabilidade das bibliotecas usadas" é apenas algo que não foi feito, nem positivo nem negativo.
No entanto, com a existência de atacantes, transformar "o que não foi feito" em "o que não foi possível/não foi percebido" como algo negativo, não é uma situação muito triste?

Não se pode negar que a visão de "bater na pedra antes de atravessar a ponte" é influenciada pela sociedade e cultura empresarial japonesa moderna.
Casos em que vulnerabilidades como injeção SQL foram introduzidas e causaram danos por atacantes continuam ocorrendo, e há casos em que a responsabilidade da empresa desenvolvedora é questionada em tribunal.
Também há casos em que a falta de cuidado no trabalho leva a grandes acidentes.

No entanto, se todos esses problemas forem tratados como "problemas da empresa desenvolvedora/desenvolvedor", acredito que o desenvolvimento de TI como um todo se encolherá.
Quem realmente é mau é o atacante que explora as vulnerabilidades.
Pensando assim, o desenvolvedor ou empresa desenvolvedora que "não fez / não foi possível / não percebeu" não seria mais uma vítima do que um agressor?
Se for assim, em vez de apontar "você é culpado por não ter feito / não ter sido possível / não ter percebido", acho importante estender uma mão amigável com o objetivo de caminharmos juntos, dizendo "assim fica mais seguro, podemos melhorar, vamos nos esforçar juntos", e mutualmente aprimorarmos e aproveitarmos nossas respectivas áreas de especialização.
Dessa forma, a empresa desenvolvedora/desenvolvedor pode lidar com as vulnerabilidades com tranquilidade e, depois disso, desenvolver ativamente com base na confiança.
Com ambientes de desenvolvimento seguros, alegres e cada vez mais proativos, acredito que resultados inovadores aumentarão e a sociedade japonesa se tornará mais rica.

Pessoalmente, sinto fortemente que seria bom se as seguintes ideias se difundissem no futuro.

* Desenvolvedores de campo
  * "Ter usado uma biblioteca com vulnerabilidade" não é negativo por si só.
  * Quem torna negativo é o atacante que explora a vulnerabilidade, e a própria cultura que avalia isso como negativo.
  * O fato de trabalhar seriamente no desenvolvimento todos os dias já é suficientemente positivo.
  * Lidar com vulnerabilidades não é uma tarefa de trazer algo negativo de volta a zero, mas sim um trabalho positivo para melhorar os resultados diários do desenvolvimento, tornando-os mais seguros.
* Gerentes, líderes e executivos que coordenam desenvolvedores
  * Não avaliar negativamente "o que não foi feito / não foi possível / não foi percebido". Esse tipo de visão irá desaparecendo gradualmente.
  * Parar de tratar membros que "não fizeram / não foram capazes / não perceberam" como culpados. Eles, e todos nós, somos vítimas dos atacantes que exploram as vulnerabilidades; nesse aspecto, estamos na mesma posição.
  * Parar de tentar resolver com "medidas perfeitas".

Acaba sendo um tema de "mudar a forma de ver e interpretar as coisas", envolvendo desenvolvedores, gerentes, líderes e até a alta administração, mas é claro que isso é extremamente difícil.
Afinal, como mudar?
Eu mesmo não tenho capacidade para dar a resposta correta, mas acho que há uma dica nisso.
Ou seja, talvez tenhamos que desistir de procurar a resposta correta em si.
Todo desenvolvimento de software tem algum propósito. Será que o mundo do software não se tornou tão complexo que agora é praticamente impossível buscar a "resposta correta" para realizá-lo de forma segura?
Provavelmente, sinto que o que existe é um paradigma de desenvolvimento que pressupõe "mudança", onde vários jogadores tentam, erram, obtêm feedback, trocam informações entre si e, a partir disso, se ramificam e mudam livremente.

No desenvolvimento de sistemas, os ativos de software criados uma vez são usados por vários anos, às vezes décadas.
No entanto, softwares conectados à internet, como o desenvolvimento web, ficam expostos a ambientes que mudam em meses ou anos.
Bibliotecas e frameworks usados no desenvolvimento de 5 anos atrás podem não ser mais utilizáveis.
Nesse caso, considerar a biblioteca/framework criado inicialmente como "correto" e "fixar" a versão em um paradigma de desenvolvimento traz mais desvantagens.
O mundo exterior está mudando constantemente, então é normal encontrar vulnerabilidades nas bibliotecas/frameworks que usamos.
Fixar a versão impede acompanhar essas mudanças, resultando em altos custos mentais e físicos para lidar com vulnerabilidades.
Portanto, sinto fortemente que mudar para um paradigma de desenvolvimento que pressupõe "mudar e ser capaz de acompanhar as mudanças" levará a melhores resultados a longo prazo.

Ficou longo, mas é isso.

----
Responsável: Masahiko Sakamoto (Pesquisa e Desenvolvimento, envolvido no desenvolvimento de ferramentas de diagnóstico para aplicações web internas)
* E-mail: [email protected]
* Twitter: https://twitter.com/msakamoto_sf
* Facebook: https://www.facebook.com/masahiko.sakamoto.75
* GitHub: https://github.com/msakamoto-sf

Comentários e perguntas sobre este artigo devem ser enviados ao Sakamoto.