En esta configuración, aparecen dos casos: el contenido de la clave "animal" puede referirse a la clase Dog o a la clase Cat. Por lo tanto, se necesita información adicional para saber con qué clase realizar el mapeo.

Para resolver esto, jackson-databind incorporó un procesamiento personalizado que permite incrustar el nombre de la clase de mapeo en el JSON.
Por ejemplo, como se muestra a continuación, el contenido de la clave "animal" se convierte en un arreglo, y el primer elemento especifica el nombre de la clase.```
{"animal":["Dog",{"name":"dog1","barkVolume":1.2}]}

En el resultado de la salida, hay una línea: `at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$1.run(TemplatesImpl.java:401)`.  
En este código de ejemplo, se lanza una NullPointerException, pero por el nombre del método se puede deducir que está ocurriendo algún procesamiento que implica efectos secundarios.  

Para construir un JSON que realmente logre la ejecución de código, parece necesaria una investigación adicional.  
Este artículo se limitará por ahora a presentar lo anterior, pero si se publican más artículos de investigación en otros sitios, me gustaría agregarlos aquí también.  

Por cierto, ¿dónde está implementada la lista negra? Se encuentra en la siguiente clase:  
* https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.8.9/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java#L51  

En realidad, parece que en la versión 2.8.9 hubo una omisión en esta lista negra. Ese problema es CVE-2017-15095.  

### Respuesta a CVE-2017-15095 que mejoró la lista negra  

En cuanto a la mejora de la omisión de la lista negra, primero se añadió `s.add("com.sun.rowset.JdbcRowSetImpl");` en https://github.com/FasterXML/jackson-databind/issues/1680.  
Después de que se lanzara la versión 2.9.0 con ese cambio, posteriormente se agregó la siguiente comprobación de la lista negra en https://github.com/FasterXML/jackson-databind/issues/1737.```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");

En la versión anterior a la corrección, se observa que el nombre de clase `java.util.logging.FileHandler` elude la verificación de la lista negra y, al ser instanciado, intenta abrir un archivo.
En la versión posterior a la corrección, es atrapado por la verificación de la lista negra y se lanza una excepción `JsonMappingException`.

La lista negra a partir de la versión 2.8.10 es la siguiente. La parte que comienza con el comentario `[databind#1737]` es la lista negra adicional correspondiente a 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

### Condiciones afectadas por la vulnerabilidad, grado de explotación del ataque y medidas del lado de la aplicación

Resumiendo los resultados anteriores, las condiciones necesarias para verse afectado por la vulnerabilidad de jackson-databind son las siguientes:
1. Usando jackson-databind 2.8.9 / 2.9.0 o inferior
2. Procesando JSON obtenido de una fuente no confiable de una de las siguientes maneras:
   * Llamar a `ObjectMapper.enableDefaultTyping()` antes de deserializar.
   * No se llama a `ObjectMapper.enableDefaultTyping()`, pero se utiliza la anotación `@JsonTypeInfo` en la declaración de clase para permitir el mapeo y se deserializa.
   * Incluso si no se usa en el código de la aplicación, el framework puede deserializar automáticamente según el encabezado de solicitud `Accept` o la extensión de la URL.
3. Contener en el classpath clases que podrían ser explotadas mediante vulnerabilidades de serialización/deserialización de Java ("Gadget").
4. Usar tipos como `Object` en los campos miembro de la clase Java de destino que puedan aceptar clases Gadget.
   * Si se usan tipos como clases Bean específicas de la aplicación que sean incompatibles con las clases utilizadas en los Gadget, es posible rechazar la instanciación con un error de verificación de tipo antes de crear la instancia (excepto si la propia clase Bean específica de la aplicación contiene vulnerabilidades de deserialización).

En cuanto a si realmente se ve afectado, parece depender en gran medida del código del lado de la aplicación, como la forma de usar/configurar `ObjectMapper`, la combinación de la anotación `@JsonTypeInfo`, los campos miembro de la clase destino, etc.

Además, si los nombres de clave en el JSON no existen en la clase Java de destino, Jackson simplemente los ignora. Por lo tanto, para que un ataque tenga éxito, es necesario personalizarlo según el JSON de cada aplicación, y parece muy difícil crear código de ataque que pueda reutilizarse en múltiples aplicaciones.

Además, con respecto a la condición 4, en la práctica común, no se suele declarar un campo de clase Java como tipo `Object`. Las clases que permiten la ejecución de código arbitrario son, en su mayoría, incompatibles con las clases Bean creadas en la aplicación.

Por lo tanto, parece baja la posibilidad de que ocurran ataques a gran escala o que realmente se explote esta vulnerabilidad para causar daños (es decir, que el ataque tenga éxito).

En cuanto a las medidas del lado de la aplicación, para la condición 3, dado que también se pueden explotar clases incluidas en el JDK, parece que prácticamente no se puede mitigar. Por lo tanto, la medida básica es actualizar jackson-databind a la última versión. Si no se puede actualizar a la última versión, será necesario eliminar la llamada a `ObjectMapper.enableDefaultTyping()` o la anotación `@JsonTypeInfo` y rediseñar para no depender de ellas. Por ejemplo, se podría crear un serializador personalizado.

Sin embargo, si ya se está utilizando como una API invocable de forma remota, no se puede cambiar el formato JSON tan fácilmente. En cuanto a la anotación `@JsonTypeInfo`, parece que, según la configuración, se pueden limitar las subclases o aceptar solo los nombres de clase previstos por el programador. Consulte los siguientes documentos para más detalles.
* JacksonPolymorphicDeserialization
  * https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

#### Sobre los pros y contras de la mitigación mediante lista negra y la creación de un deserializador personalizado

jackson-databind 2.8.10 / 2.9.1 abordó CVE-2017-7525 y CVE-2017-15095 mediante una lista negra. Sin embargo, como es evidente en los problemas relacionados con OGNL en Struts2, la mitigación mediante lista negra no es perfecta. (Personalmente, creo que es una medida efectiva hasta cierto punto para el nivel de los llamados 'script kiddies' que solo usan herramientas de escaneo).

Por lo tanto, si se desea una mitigación realmente fundamental, el autor considera que es importante deshabilitar o no usar funciones como `ObjectMapper.enableDefaultTyping()` que incrustan información de clase en el JSON. Entonces, ¿cómo se puede resolver el problema que `ObjectMapper.enableDefaultTyping()` pretendía resolver?

El autor tampoco tiene una solución alternativa que pueda considerarse correcta. La raíz del problema es 'poder mapear clases Java ambiguas sin depender de JSON no confiable'. Como enfoque para hacerlo posible, el autor piensa que podría ser crear un deserializador personalizado. Un deserializador personalizado permite recibir JSON durante la deserialización y controlar el objeto generado desde el código del programa.

Por ejemplo, si llega `{"animal":{"name":"dog1","barkVolume":1.2}}`, se puede determinar que 'como hay una clave `barkVolume`, se instancia como clase Dog'; o si llega `{"animal":{"name":"cat1","likesCream":true,"lives":10}}`, se puede determinar que 'como hay claves `likesCream` y `lives`, se instancia como clase Cat'. Usando esto, no es necesario incrustar el nombre de clase en el JSON.

Personalmente, tengo la impresión de que el formato JSON con nombres de clase incrustados dificulta la interoperabilidad con otros lenguajes/bibliotecas (si conoce alguna otra extensión similar en otros lenguajes/bibliotecas, por favor hágamelo saber). Si se asume la interoperabilidad con otros sistemas, parece más razonable crear un deserializador personalizado en Jackson que forzar a los demás a incrustar nombres de clase según las necesidades de Jackson.

Creo que hay otras soluciones, por lo que agradecería que los lectores compartieran sus opiniones si tienen alguna otra solución. (Un ejemplo extremo sería no mapear a clases individuales, sino deserializar todo en formato `Map<String, Object>` o `List<String, Object>`).

He encontrado algunos artículos de referencia para crear deserializadores personalizados; aunque están en inglés, dejo los enlaces.
* 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 de jackson-databind (versiones 2.8, 2.9):
* https://fasterxml.github.io/jackson-databind/javadoc/2.8/
* https://fasterxml.github.io/jackson-databind/javadoc/2.9/

El autor también ha creado un código de ejemplo de deserializador personalizado; espero que sirva como sugerencia.
* [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)

## Acerca de S2-055

Hasta ahora hemos visto las vulnerabilidades de Jackson. Ahora, ¿cómo afectan realmente al plugin REST de Struts2? Lo hemos verificado usando struts2-rest-showcase incluido en Struts2.

El uso del plugin REST de Struts se basó en lo siguiente:
* http://struts.apache.org/plugins/rest/

### El plugin REST de Struts2 no llama a ObjectMapper.enableDefaultTyping()

Por cierto, las condiciones para ser vulnerable en CVE-2017-7525 eran las siguientes:
* Procesando JSON obtenido de una fuente no confiable de una de las siguientes maneras:
  * Llamar a `ObjectMapper.enableDefaultTyping()` antes de deserializar.
  * No se llama a `ObjectMapper.enableDefaultTyping()`, pero se utiliza la anotación `@JsonTypeInfo` en la declaración de clase para permitir el mapeo y se deserializa.

Al verificar si el plugin REST de Struts2 contiene código que cumpla estas condiciones, se confirmó que no incluye ninguna. De hecho, en la versión 2.5.14 anterior a la corrección, ni `ObjectMapper.enableDefaultTyping()` ni `@JsonTypeInfo` se usaban en el plugin REST ni en todo el árbol de fuentes de Struts2 tras una búsqueda con grep.
* https://github.com/apache/struts/tree/STRUTS_2_5_14

En todo el árbol de fuentes de Struts2, la única clase que usa ObjectMapper de Jackson es org.apache.struts2.rest.handler.JacksonLibHandler. Al verificar el código fuente, ciertamente no se utiliza `ObjectMapper.enableDefaultTyping()` en la versión 2.5.14.
* https://github.com/apache/struts/blob/STRUTS_2_5_14/plugins/rest/src/main/java/org/apache/struts2/rest/handler/JacksonLibHandler.java
  * Este archivo Java no ha cambiado en 2.5.14.1.

Por lo tanto, se considera que el plugin REST en sí no tenía problemas con CVE-2017-7525 incluso en la versión 2.5.14. La vulnerabilidad ocurre cuando la aplicación establece `@JsonTypeInfo` en los campos de las clases que mapean el JSON. Por lo tanto, en la verificación con struts2-rest-showcase a continuación, se ha configurado `@JsonTypeInfo` en los campos de destino agregados en el lado de la aplicación.

Por cierto, en Struts2 también hay un plugin JSON.
* http://struts.apache.org/plugins/json/
* Al revisar el código fuente del plugin JSON, en su pom.xml no incluye otras bibliotecas JSON como dependencias.
* Parece que implementa su propio procesamiento JSON.
* https://github.com/apache/struts/tree/STRUTS_2_5_14/plugins/json
* Por lo tanto, se cree que la vulnerabilidad de jackson-databind no afecta al plugin JSON.

### Hacer que struts2-rest-showcase sea compatible con Jackson

struts2-rest-showcase es un ejemplo que implementa CRUD de la clase Order usando el plugin REST. Aquí agregaremos las clases Zoo, Animal, Cat, Dog utilizadas en el código de ejemplo de vulnerabilidad de Jackson, y un ZooController para procesar su CRUD en JSON.

Consulte el código fuente completo a continuación. (Este artículo ha verificado la compilación y ejecución con JDK8)
* [rest-showcase](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/tree/master/rest-showcase)

Principales modificaciones:
* Se cambió el puerto de escucha del plugin jetty-maven-plugin a 18088. (`mvn jetty:run`)
* Se agregaron jackson-core y jackson-databind como dependencias.
* Se agregaron las clases Zoo, Animal(abstract), Dog, Cat. Se agregó la clase ZooService como capa de servicio.
* Se agregó un ZooController con CRUD mínimo. (Se omitió la vista JSP)
* En struts.xml se cambió el manejador JSON a JacksonLibHandler.
* Se incorporó maven-wrapper para que, si solo se tiene JDK, se pueda compilar y ejecutar directamente con mvnw / mvnw.bat.

Compilación y ejecución:
1. Después de clonar el repositorio, vaya al directorio rest-showcase y ejecute `mvnw jetty:run`. (Tenga en cuenta que la primera ejecución descargará Maven, lo que puede demorar unos minutos o incluso más de 10 minutos dependiendo del caso).
1. Acceda a http://localhost:18088/struts2-rest-showcase/; si se muestra la lista de Orders, es exitoso.
1. Para finalizar la ejecución, puede usar Ctrl-C.
1. Si modifica archivos Java, finalice con Ctrl-C y ejecute nuevamente `mvnw jetty:run`.

Verificación de funcionamiento con comando curl: (asumiendo que se pasa a través del proxy local http localhost:8080)```
一覧取得:
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

Aquí, enviaremos una solicitud JSON mediante el método POST y llamaremos al 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}}'

Por lo tanto, descomenta y habilita el `@JsonTypeInfo` del campo `animal`. Detén la aplicación web con Ctrl-C y vuelve a ejecutar `mvnw jetty:run`.```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` が返されます。一覧取得をしてみると、たしかに追加されたことを確認できます。

### Struts2 REST plugin 2.5.14 で CVE-2017-7525 を確認

リポジトリの pom.xml では `<parent>` の struts のartifactで、バージョンを 2.5.14 を指定しているため、そのままではCVE-2017-7525に脆弱です。
それを確認するため、以下のcurlコマンドを実行してみます。クラス名とその中身は cve-2017-7525-check.groovy を参考にしていますので、jackson-databind 2.8.8 の時と同じ反応が返されれば、脆弱であると考えられます。```
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":{}}]}'

Parece que se produjo una `IllegalArgumentException` porque el tipo del campo `animal` es la clase `Animal`, que no es un subtipo de la clase `com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl`.

Ahora, modifiquemos el campo `animal` de `Zoo.java` al tipo `Object` y ejecutemos `mvnw jetty:run` de nuevo.```java
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    //public Animal animal;
    public Object animal;

Esta es la misma excepción de caso vulnerable que se verificó con cve-2017-7525-check.groovy.

Por lo anterior, se confirmó la existencia de la vulnerabilidad CVE-2017-7525 de jackson-databind en el plugin Struts2 REST 2.5.14.

Además, se supo que es necesario usar el tipo Object además de `@JsonTypeInfo`.

Lo siguiente es una opinión personal del autor, pero no parece común especificar deliberadamente una clase que sea compatible con la clase Object o clases que puedan usarse como Gadget en vulnerabilidades de deserialización de Java como tipo de campo en clases de datos al crear una API REST. Por lo tanto, siento que puede ser difícil tener éxito en un ataque real.

### Confirmación de la corrección en Struts2 REST plugin 2.5.14.1

Entonces, verifiquemos si la vulnerabilidad fue corregida en la versión 2.5.14.1.

Modifique la versión del artifact `<parent>` en pom.xml a 2.5.14.1, reinicie con `mvnw jetty:run` y ejecute el mismo 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":{}}]}'

これは cve-2017-7525-check.groovy で検証した時と同じ、脆弱性が修正された後の例外です。

Eclipse等のMavenに対応したIDEで開いて、依存性を解決した後のjackson-databindのバージョンを見てみると、たしかに 2.9.2 になっていることが確認できると思います。IDEがない場合は、 `mvnw help:effective-pom` で最終的なpomを出力できますので、そこで jackson-databind を検索すれば version 2.9.2 を使用していることを確認できると思います。

CVE-2017-15095 については省略しますが、以上より 2.5.14.1 で jackson-databind の脆弱性に対応できたことを確認できました。

### PoC de S2-055

※ Añadido el 2017-12-08

Se han publicado un artículo de investigación y un informe PoC sobre S2-055.
* S2-055漏洞环境搭建与分析 | 绿盟科技博客
  * http://blog.nsfocus.net/s2-055/

Si lo leemos con la ayuda de Google Translate, parece que [los autores] tienen la misma opinión sobre las condiciones de explotación y la viabilidad del ataque.

De hecho, se ha modificado rest-showcase y se muestra un PoC de comunicación HTTP donde se inició una calculadora.

Tomando solo la parte JSON, probé primero con Jackson solo, y el siguiente es el código de muestra.
* [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)

Cuando se ejecuta especificando la versión 2.8.8 aquí, en el entorno del autor se obtuvo la siguiente salida.```
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)
(...)

Aquí, durante el mismo mes, se lanzó la versión 2.9.0 como una corrección adicional para contrarrestar la black-list.
* https://github.com/FasterXML/jackson-databind/issues/1680

Esto fue añadido:```java
s.add("com.sun.rowset.JdbcRowSetImpl");

### 2017-08

* Se lanza la versión 2.8.10, que aborda los issues #1680, #1737.
* Además, en agosto se abren los siguientes issues, y se discute de manera integral la respuesta como CVE-2017-7525.
  * https://github.com/FasterXML/jackson-databind/issues/1723
* En el blog de Adam Caudill se publica una explicación del exploit de CVE-2017-7525.
  * https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/

### 2017-09

* Se lanza la versión 2.9.1, que aborda el issue #1737.

### 2017-10

En el siguiente bugzilla, se inicia el trabajo para aplicar la lista negra de las versiones 2.8.10 / 2.9.1, ya que la corrección de CVE-2017-7525 en las versiones 2.8.9 / 2.9.0 era insuficiente, y se identifica como CVE-2017-15095.
* https://bugzilla.redhat.com/show_bug.cgi?id=1506612

### 2017-11

* RedHat publica información sobre CVE-2017-15095.
  * https://access.redhat.com/security/cve/cve-2017-15095

* En el issue de jackson-databind también se intercambian preguntas y respuestas sobre el estado de la respuesta a CVE-2017-15095.
  * https://github.com/FasterXML/jackson-databind/issues/1847
  * Se responde que ya está cubierto en las versiones 2.8.10 / 2.9.1.

### 2017-12

* Se publica un artículo explicativo en el blog de desarrolladores de Scutum, un WAF en la nube.
  * https://www.scutum.jp/information/waf_tech_blog/2017/12/waf-blog-052.html
  * En este artículo se menciona que, en la lista negra de la versión 2.9.3, hay una deficiencia en la clase de Spring que, aunque no representa un problema urgente, podría dar lugar a una nueva actualización.
  * También se debate si la responsabilidad de esta vulnerabilidad recae realmente en la biblioteca o más bien en la aplicación.

## Sobre las tendencias futuras de vulnerabilidades relacionadas con la serialización/deserialización en Java

Desde hace un par de años, tengo la impresión de que han aumentado los informes de vulnerabilidades relacionadas con la serialización/deserialización en Java.
Por ejemplo, la información sobre vulnerabilidades de productos Pivotal, incluido Spring, se publica en https://pivotal.io/security/. De hecho, en 2017, además de CVE-2017-4995, se publicaron las siguientes vulnerabilidades:

* https://pivotal.io/security/cve-2017-8045
  * RCE debido a un problema de deserialización de `org.springframework.amqp.core.Message` en Spring AMQP.
* https://pivotal.io/security/cve-2017-8046
  * RCE debido a una deficiencia en el manejo de JSON con el método PATCH en Spring Data REST.

Dado que son vulnerabilidades que fácilmente conducen a RCE, parece que tanto atacantes como investigadores de vulnerabilidades están prestando especial atención a la serialización/deserialización en Java.
Creo que durante los próximos años seguirán apareciendo informes de vulnerabilidades relacionadas con procesos de serialización/deserialización.
Dicho esto, al igual que con Jackson, en el desarrollo actual, donde el intercambio de datos a través de API remotas se ha vuelto algo común y las bibliotecas agilizan el desarrollo, me imagino que en muchos entornos no es realista no utilizar serialización/deserialización en absoluto, o crearla desde cero.
Personalmente, creo que lo importante es construir una cultura y un entorno de desarrollo ágil que permita actualizar las bibliotecas lo antes posible cuando se publique una vulnerabilidad.

Tenía algo que reflexionar a nivel mental sobre cómo afrontar las vulnerabilidades del middleware, las bibliotecas y los frameworks de los que dependemos, así que lo he plasmado como una reflexión a continuación.

## Reflexión

Cuando vi la información de que se habían publicado S2-054 y S2-055, y que esto se debía a la vulnerabilidad de Jackson, me impactó bastante.
Y es que unos días antes, un compañero me había preguntado: "¿Qué biblioteca recomiendas para parsear JSON en Java?", y yo, con aires de suficiencia, le había respondido: "Jackson es muy utilizado en OSS y tiene un historial probado. Como hay muchos artículos y Q&A en Google, te lo recomiendo".

Yo mismo había utilizado Jackson en el desarrollo de herramientas internas de la empresa y había experimentado su conveniencia.
Sin embargo, en ese momento no conocía CVE-2017-7525, y me sentía tranquilo porque Jackson era ampliamente utilizado en OSS y tenía muchos usuarios.

Entonces, otro compañero encontró el blog de Adam Caudill y me informó de la existencia de CVE-2017-7525. Unos días después de haber recomendado Jackson con tanta seguridad, se publicó una actualización de Struts2 debido a la vulnerabilidad de Jackson. Además, la vulnerabilidad de Jackson ya había sido solucionada varios meses antes. Como ingeniero en el sector de la seguridad, no tengo excusa si se me acusa de haber descuidado la recopilación de información sobre vulnerabilidades de las bibliotecas que uso (aunque solo puedo decir que así fue).

Por eso, durante los últimos días, mi estado mental fue pésimo (aumento de la presión arterial y el pulso, temblor en las manos, ganas de llorar sin estar triste, palpitaciones incesantes, etc.). Para intentar solucionarlo, decidí empezar por entender qué era CVE-2017-7525 y cuál era exactamente la situación de Jackson, y dediqué el fin de semana a investigar y redactar este artículo.

Al reflexionar sobre esto, reconozco que cuando uno se dedica al desarrollo, es difícil prestar atención a la información de actualización de las bibliotecas de las que depende.
En medio de las continuas tareas de desarrollo, es prácticamente imposible realizar una investigación completa de todas las funcionalidades y aspectos de calidad, como las vulnerabilidades, de todas las bibliotecas utilizadas.
Por otro lado, las funcionalidades exigidas al desarrollo son cada vez mayores, y es poco realista desarrollarlas todas desde cero.
En algún momento, es necesario "confiar" en las bibliotecas que se utilizan para agilizar el desarrollo.
Sin embargo, también es muy difícil rastrear toda la información de actualización de las herramientas y bibliotecas utilizadas en el trabajo diario y estar atento a si incluyen correcciones de problemas de seguridad.
Por supuesto, soy consciente de que existen servicios que, al registrar las herramientas y bibliotecas utilizadas, distribuyen información de actualización para ayudar a resolver este problema.

Lo que sentí con el deterioro de mi estado mental fue que tenía un fuerte "sentimiento de autoculpabilidad y remordimiento por no haber hecho algo".
Me estaba etiquetando negativamente a mí mismo: "A pesar de ser ingeniero de seguridad, no estaba al tanto de la información de vulnerabilidades de la biblioteca que uso...".
Incluso los desarrolladores generales que no están relacionados con la industria de la seguridad probablemente albergan arrepentimientos y ansiedades como: "Si no hubiera propuesto Struts2 en ese momento..." o "Debo gestionar más estrictamente el ciclo de vida de las bibliotecas/frameworks (= me preocupa la situación actual en la que no lo hago)".

Si intentáramos "resolver" esto de frente como un "problema", tendríamos que recopilar información sobre vulnerabilidades una por una, verificar el código fuente y las funcionalidades de las bibliotecas y frameworks que planeamos usar, investigar a fondo si se consideran estándares de facto y, después del inicio de la operación, realizar una gestión rigurosa del ciclo de vida.

Sin embargo, ¿es realmente posible ese enfoque de "golpear el puente de piedra antes de cruzarlo" en los diversos entornos de desarrollo actuales?

Al escribir este artículo, pensé que la era de considerar las "cosas que no se hicieron / no se pudieron hacer / no se notaron" como causas o culpables, y eliminarlas (= hacerlas posibles) como la única "solución al problema", quizás ya haya terminado.
En una cultura así, a menos que uno sea perfecto, los desarrolladores tendrán que enfrentarse continuamente a sus propias "cosas que no hicieron, no pudieron hacer o no notaron".
Dado que no existen personas perfectas, creo que solo aquellos con una fortaleza mental considerable podrían soportarlo.

En los problemas de seguridad del software, quien realmente causa el daño es el atacante. Quien pone la situación en negativo es el atacante que explota las vulnerabilidades.

La mayoría de los desarrolladores, en esencia, trabajan en el desarrollo con buena fe y seriedad. En ese punto, ya están en positivo.
"No gestionar el ciclo de vida de las bibliotecas/frameworks" o "no recopilar ni monitorear la información de vulnerabilidades de las bibliotecas utilizadas" es simplemente algo que no se hace, y no es ni positivo ni negativo.
Sin embargo, debido a la existencia de atacantes, que lo "no hecho" se convierta en negativo como "lo que no se pudo hacer / no se notó", ¿no es una situación demasiado triste?

No se puede negar que la mentalidad de "golpear el puente de piedra antes de cruzarlo" está influenciada por la sociedad japonesa moderna y la cultura empresarial.
De hecho, hay casos en los que se introducen vulnerabilidades como la inyección SQL, se producen daños por atacantes, y se responsabiliza a la empresa desarrolladora en los tribunales.
También hay casos en los que la negligencia en el trabajo conduce a accidentes graves.

Sin embargo, si todo eso se reduce a un problema de la "empresa desarrolladora/desarrollador", creo que el desarrollo de TI en general se vuelve tímido.
Quien es realmente malo es el atacante que explota las vulnerabilidades.
Si lo pensamos así, ¿no se podría decir que los desarrolladores y las empresas desarrolladoras que "no hacen / no pueden hacer / no notan" son más bien víctimas que perpetradores?
Si es así, en lugar de señalar a las víctimas diciendo "es tu culpa por no hacer / no poder / no notar", creo firmemente que es importante tender una mano cálida con el objetivo de caminar juntos, diciendo "si haces esto, será más seguro; podemos mejorar, esforcémonos juntos", y mientras tanto, superarnos y aprovecharnos mutuamente en nuestras respectivas áreas de especialización.
Si eso sucede, las empresas desarrolladoras y los desarrolladores podrán abordar las vulnerabilidades con tranquilidad, y luego será más fácil desarrollar activamente sobre una base segura.
Si los entornos de desarrollo se vuelven seguros, brillantes y aumentan los desarrollos proactivos, ¿no se incrementarán los resultados innovadores y la sociedad japonesa será más próspera?

Personalmente, siento firmemente que sería bueno que en el futuro se difundieran las siguientes ideas:

* Desarrolladores de campo
  * "Haber usado una biblioteca con vulnerabilidades" no es negativo en sí mismo.
  * Quien lo vuelve negativo es el atacante que explota la vulnerabilidad, y también la cultura que lo evalúa como negativo.
  * El solo hecho de trabajar seriamente en el desarrollo día a día ya es suficientemente positivo.
  * La respuesta a vulnerabilidades no es un trabajo para volver a cero desde lo negativo, sino un trabajo positivo para mejorar los resultados diarios del desarrollo hacia algo más seguro.
* Gerentes, líderes y directivos que supervisan a los desarrolladores
  * No evalúen negativamente "lo que no se hizo / no se pudo hacer / no se notó". Esa mentalidad se desvanecerá gradualmente en el futuro.
  * Dejen de tratar a los miembros que "no hicieron / no pudieron hacer / no notaron" como culpables. Ellos, y todos nosotros, somos víctimas de los atacantes que explotan las vulnerabilidades; desde ese punto de vista, estamos en la misma posición.
  * Abandonen el enfoque de resolverlo todo con "medidas perfectas".

Esto implica cambiar la "forma de ver y percibir las cosas", involucrando a desarrolladores, gerentes, líderes e incluso la alta dirección, pero es evidente que es extremadamente difícil.
En primer lugar, ¿cómo deberíamos cambiarlo?
Yo mismo no tengo la capacidad para dar la respuesta correcta, pero creo que ahí hay una pista.
Es decir, que quizás ya no quede más remedio que rendirse en la búsqueda de la respuesta correcta.
Todo desarrollo de software tiene algún propósito. ¿Acaso el mundo del software no se ha vuelto tan complejo que ahora es casi imposible buscar la "respuesta correcta" para lograrlo de manera segura y segura?
Probablemente lo que hay allí es un paradigma de desarrollo que presupone el "cambio", donde múltiples jugadores prueban y yerran a su manera, intercambian información tras obtener retroalimentación, y desde ahí se ramifican y cambian libremente.

En el desarrollo de sistemas, los activos de software creados una vez se utilizan durante varios años, a veces décadas.
Sin embargo, el software conectado a Internet, como el desarrollo web, está expuesto a entornos que cambian en cuestión de meses o años.
Puede que las bibliotecas y frameworks utilizados en un desarrollo de hace cinco años ya no sean funcionales.
En ese caso, en un paradigma de desarrollo que considera la biblioteca/framework inicial como la "respuesta correcta" y "fija" la versión, las desventajas superan a las ventajas.
El mundo exterior cambia constantemente, por lo que es normal que se encuentren vulnerabilidades en las bibliotecas/frameworks que se utilizan.
Si se fija la versión, no se puede seguir ese cambio y, como resultado, se pagan costos mentales y físicos enormes en la respuesta a vulnerabilidades.
Por lo tanto, siento firmemente que, a largo plazo, cambiar a un paradigma de desarrollo que presuponga "poder cambiar y adaptarse al cambio" conducirá a mejores resultados.

Ha sido largo, pero esto es todo.

----
Responsable: Masahiko Sakamoto (Perteneciente al Departamento de I+D, dedicado al desarrollo de herramientas de diagnóstico de aplicaciones web de uso interno)
* Correo: [email protected]
* Twitter: https://twitter.com/msakamoto_sf
* Facebook: https://www.facebook.com/masahiko.sakamoto.75
* GitHub: https://github.com/msakamoto-sf

Para cualquier opinión o consulta sobre este artículo, diríjase a Sakamoto.