В этой конфигурации появляются два случая: когда содержимое ключа "animal" ссылается на класс Dog и когда на класс Cat. Следовательно, требуется дополнительная информация о том, какой класс использовать для маппинга.

Чтобы решить эту проблему, jackson-databind встроил собственную обработку, позволяющую встраивать имя класса для маппинга в JSON.
Например, как показано ниже, содержимое ключа "animal" помещается в массив, а в первом элементе указывается имя класса.```
{"animal":["Dog",{"name":"dog1","barkVolume":1.2}]}

В выходных данных есть строка `at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$1.run(TemplatesImpl.java:401)`.  
В этом примере кода выбрасывается исключение NullPointerException, но, судя по имени метода, можно предположить, что происходит какая-то обработка с побочными эффектами.

Чтобы собрать JSON, позволяющий успешно выполнить код, потребуется дополнительное исследование.  
В данной статье мы пока ограничимся этим введением, но если на других сайтах появятся дальнейшие исследовательские статьи, мы хотели бы добавить их сюда.

Кстати, где же реализован решающий чёрный список? Он находится в следующем классе:  
* https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.8.9/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java#L51

Оказывается, по состоянию на версию 2.8.9 в этом чёрном списке была утечка. Эта проблема обозначена как CVE-2017-15095.

### Исправление CVE-2017-15095, улучшающее чёрный список

Что касается устранения утечки в чёрном списке: сначала в https://github.com/FasterXML/jackson-databind/issues/1680 была добавлена строка `s.add("com.sun.rowset.JdbcRowSetImpl");`.  
После того как с этим изменением был выпущен релиз 2.9.0, в 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");

В предыдущих версиях имя класса `java.util.logging.FileHandler` обходило проверку в черном списке, и при создании экземпляра действительно предпринималась попытка открыть файл.  
В последующей версии черный список перехватывает его, и выбрасывается исключение `JsonMappingException`.

На данный момент черный список в версии 2.8.10 выглядит следующим образом. Строки, начинающиеся с комментария `[databind#1737]`, являются дополнительным черным списком для 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

### Об условиях подверженности уязвимости, реализуемости атаки и мерах защиты на стороне приложения

Если обобщить приведенные выше результаты, то для подверженности уязвимости jackson-databind необходимо выполнение следующих условий:
1. Используется jackson-databind 2.8.9 / 2.9.0 или ниже.
2. Для JSON, полученного из ненадёжного источника, выполняется одна из следующих операций:
   * Десериализация производится после вызова `ObjectMapper.enableDefaultTyping()`.
   * `ObjectMapper.enableDefaultTyping()` не вызывается, но в объявлении класса используется аннотация `@JsonTypeInfo`, позволяющая выполнять отображение, и производится десериализация.
   * Даже если приложение не использует это напрямую, фреймворк может автоматически выполнять десериализацию в зависимости от заголовка запроса `Accept` или расширения URL.
3. В classpath присутствуют классы ("Gadget"), которые могут быть использованы в уязвимостях Java-сериализации/десериализации.
4. В полях-членах целевого Java-класса для отображения используются такие типы, как `Object`, которые могут принимать классы-гаджеты.
   * Если в качестве типа используется несовместимый с классами-гаджетами специфичный для приложения bean-класс, то до фактического создания экземпляра произойдёт ошибка проверки типа, и он будет отброшен (за исключением случаев, когда сам bean-класс содержит уязвимость десериализации).

Действительная подверженность, по-видимому, сильно зависит от кода приложения: от способа использования / конфигурации `ObjectMapper`, от комбинаций аннотаций `@JsonTypeInfo`, а также от полей-членов целевого класса и т.д.

Кроме того, если имя ключа в JSON отсутствует в Java-классе, в который производится десериализация, Jackson просто игнорирует его.  
Поэтому для успешной атаки требуется адаптация к JSON конкретного приложения, и создать код атаки, который можно было бы использовать в нескольких приложениях, представляется очень сложным.

Далее, по поводу условия 4: при обычном стиле программирования поля Java-класса вряд ли будут специально объявлены как `Object`.  
Большинство классов, позволяющих выполнить произвольный код, скорее всего, несовместимы с создаваемыми в приложении bean-классами.

Исходя из вышесказанного, вероятность массовых атак или фактического нанесения ущерба (т.е. успешной атаки) с использованием этой уязвимости представляется низкой.

Что касается мер на стороне приложения: по условию 3, поскольку возможно использование классов, входящих в состав JDK, защита практически невозможна.  
Поэтому основная мера — обновление jackson-databind до последней версии.  
Если обновление jackson-databind невозможно, необходимо удалить вызовы `ObjectMapper.enableDefaultTyping()` и аннотации `@JsonTypeInfo`, переработав архитектуру так, чтобы не зависеть от них. Например, можно создать собственный сериализатор.

Однако если API уже используется как удалённо вызываемый, легко изменить JSON-формат не получится.  
Существуют настройки аннотации `@JsonTypeInfo`, позволяющие ограничить подклассы, то есть принимать только имена классов, ожидаемые программистом.  
Подробности см. в следующей документации:  
* JacksonPolymorphicDeserialization
  * https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

#### О целесообразности защиты с помощью черного списка и создании пользовательского десериализатора

jackson-databind 2.8.10 / 2.9.1 устраняют CVE-2017-7525 и CVE-2017-15095 с помощью черного списка.  
Однако, как ясно из проблем, связанных с OGNL в Struts2, защита с помощью черного списка не является абсолютной.  
(Лично автор считает, что для уровня так называемых «скрипткидди», которые просто используют инструменты сканирования, эта мера достаточно эффективна.)

Поэтому для действительно кардинальной защиты, по мнению автора, важно отключить или не использовать саму функцию встраивания информации о классе в JSON, такую как `ObjectMapper.enableDefaultTyping()`.

Но как же тогда решить проблему, которую изначально пытался решить `ObjectMapper.enableDefaultTyping()`?

У самого автора нет альтернативного решения, которое можно было бы назвать правильным.  
Суть проблемы, на мой взгляд, в том, чтобы иметь возможность выполнять отображение, когда целевой Java-класс неоднозначен, не полагаясь на ненадёжный JSON.  
Подходом, который может это обеспечить, вероятно, является создание пользовательского десериализатора.  
Пользовательский десериализатор позволяет программно управлять создаваемым объектом, получая JSON во время десериализации.

Например, при получении `{"animal":{"name":"dog1","barkVolume":1.2}}` можно определить: «есть ключ `barkVolume`, значит создаём экземпляр класса Dog».  
А при получении `{"animal":{"name":"cat1","likesCream":true,"lives":10}}` — «есть ключи `likesCream` и `lives`, значит создаём экземпляр класса Cat».  
Это избавляет от необходимости встраивать имя класса в JSON.

Лично автору формат JSON со встроенным именем класса кажется создающим проблемы для совместимости с другими языками / библиотеками (если кто-нибудь знает аналогичное расширение в других языках или библиотеках, сообщите).  
При условии взаимодействия с другими системами, вероятно, более правильным будет создание пользовательского десериализатора на стороне Jackson, а не просьба встраивать имя класса специально для Jackson.

Думаю, есть и другие решения, поэтому автор будет рад, если читатели предложат свои варианты.  
(Как крайний пример, существует подход — десериализовать всё в `Map<String, Object>` или `List<String, Object>` вместо отображения на отдельные классы.)

Нашёл несколько статей для справки по созданию пользовательского десериализатора (на английском), привожу ссылки:
* 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 jackson-databind (2.8.x, 2.9.x):
* https://fasterxml.github.io/jackson-databind/javadoc/2.8/
* https://fasterxml.github.io/jackson-databind/javadoc/2.9/

Автор также подготовил пример кода пользовательского десериализатора. Надеюсь, он послужит подсказкой.
* [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)

## Об S2-055

До сих пор мы рассматривали уязвимость самого Jackson. Теперь посмотрим, как она на самом деле влияет на REST plugin Struts2. Мы проверили это с помощью struts2-rest-showcase, входящего в Struts2.

По поводу использования Struts REST plugin см.:
* http://struts.apache.org/plugins/rest/

### В REST plugin Struts2 не вызывается ObjectMapper.enableDefaultTyping()

Между прочим, в CVE-2017-7525 к условиям фактической уязвимости относились:
* Для JSON, полученного из ненадёжного источника, выполняется одна из следующих операций:
  * Десериализация производится после вызова `ObjectMapper.enableDefaultTyping()`.
  * `ObjectMapper.enableDefaultTyping()` не вызывается, но в объявлении класса используется аннотация `@JsonTypeInfo`, позволяющая выполнять отображение, и производится десериализация.

Мы проверили, есть ли в REST plugin Struts2 код, соответствующий этим условиям, и обнаружили, что ни то, ни другое не присутствует.  
Фактически, в версии 2.5.14 (до исправления) ни `ObjectMapper.enableDefaultTyping()`, ни `@JsonTypeInfo` не используются ни в самом REST plugin, ни во всём дереве исходников Struts2 по результатам grep.
* https://github.com/apache/struts/tree/STRUTS_2_5_14

Во всём дереве исходников Struts2 Jackson ObjectMapper используется только в классе `org.apache.struts2.rest.handler.JacksonLibHandler`. Проверив исходный код, в версии 2.5.14 действительно не обнаружили вызова `ObjectMapper.enableDefaultTyping()`.
* https://github.com/apache/struts/blob/STRUTS_2_5_14/plugins/rest/src/main/java/org/apache/struts2/rest/handler/JacksonLibHandler.java
  * В версии 2.5.14.1 содержимое этого Java-файла не изменилось.

Таким образом, сам REST plugin в версии 2.5.14, по-видимому, не был подвержен CVE-2017-7525.  
Уязвимость возможна только в том случае, если в приложении в поле класса, отображаемого на JSON, установлена аннотация `@JsonTypeInfo`.  
Поэтому в последующей проверке с помощью struts2-rest-showcase мы установили `@JsonTypeInfo` в поле целевого класса, добавленного на стороне приложения.

Кстати, в Struts2 существует также JSON plugin.
* http://struts.apache.org/plugins/json/
* Если посмотреть исходники JSON plugin, в pom.xml нет зависимостей от других JSON-библиотек.
* Похоже, он реализует обработку JSON самостоятельно.
* https://github.com/apache/struts/tree/STRUTS_2_5_14/plugins/json
* Поэтому уязвимость jackson-databind, вероятно, не затрагивает JSON plugin.

### Адаптация struts2-rest-showcase для Jackson

struts2-rest-showcase — это пример реализации CRUD для класса Order с помощью REST plugin. Мы добавим в него классы Zoo / Animal / Cat / Dog, использовавшиеся в примере кода для уязвимости Jackson, а также ZooController для обработки CRUD этих классов в формате JSON.

Полный исходный код приведён ниже (сборка и запуск проверены на JDK8):
* [rest-showcase](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/tree/master/rest-showcase)

Основные изменения:
* Порт прослушивания плагина jetty-maven-plugin изменён на 18088 (`mvn jetty:run`).
* Добавлены зависимости jackson-core, jackson-databind.
* Добавлены классы Zoo, Animal (абстрактный), Dog, Cat. В качестве сервисного слоя добавлен класс ZooService.
* Добавлен ZooController с минимальным CRUD (JSP для представления опущены).
* В struts.xml обработчик для JSON изменён на JacksonLibHandler.
* Встроен maven-wrapper, чтобы можно было собрать и запустить с помощью mvnw / mvnw.bat при наличии только JDK.

Сборка и запуск:
1. Клонируйте репозиторий, перейдите в каталог rest-showcase и выполните `mvnw jetty:run`. (При первом запуске будет загружаться Maven, поэтому может потребоваться несколько минут или даже более 10 минут, будьте внимательны.)
2. Откройте http://localhost:18088/struts2-rest-showcase/ — если отобразится список Order, всё успешно.
3. Для остановки выполнения нажмите Ctrl-C.
4. Если вы изменили Java-файлы, остановитесь с помощью Ctrl-C и снова выполните `mvnw jetty:run`.

Проверка с помощью команды curl (при условии использования localhost:8080 в качестве локального 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

Здесь мы попробуем отправить JSON-запрос методом POST и вызвать метод 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}}'

Там убираем комментарий из поля `animal` и активируем `@JsonTypeInfo`. Останавливаем веб-приложение с помощью Ctrl-C и снова запускаем `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":{}}]}'

Тип поля `animal` — это класс Animal, который не является подтипом класса com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl, поэтому, похоже, возникло исключение IllegalArgumentException.

Теперь изменим поле `animal` в Zoo.java на тип Object и снова запустим `mvnw jetty:run`.```java
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    //public Animal animal;
    public Object animal;

Это такое же исключение, как и при проверке с помощью cve-2017-7525-check.groovy, в уязвимом случае.

Таким образом, мы подтвердили наличие уязвимости CVE-2017-7525 в jackson-databind в Struts2 REST plugin 2.5.14.

Также мы выяснили, что помимо `@JsonTypeInfo` необходимо использовать тип Object.

Ниже приведено личное мнение автора: при создании REST API, в классах данных вряд ли является обычной практикой специально указывать в качестве типа поля класс Object или классы, совместимые с классами, используемыми в качестве гаджетов в уязвимостях десериализации Java. Поэтому я считаю, что на практике успешно провести атаку будет сложно.

### Проверка исправления в Struts2 REST plugin 2.5.14.1

Итак, проверим, была ли исправлена уязвимость в версии 2.5.14.1.

Изменим версию артефакта `<parent>` в pom.xml на 2.5.14.1, перезапустим с помощью `mvnw jetty:run` и выполним ту же команду curl, что и ранее.```
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`.

Если открыть в IDE, поддерживающей Maven (например, Eclipse), и проверить версию jackson-databind после разрешения зависимостей, можно убедиться, что она действительно равна 2.9.2. Если IDE нет, можно выполнить `mvnw help:effective-pom`, чтобы вывести итоговый POM, и найти в нём `jackson-databind` — будет видно, что используется версия 2.9.2.

Описание CVE-2017-15095 опускаю, но из сказанного выше видно, что в версии 2.5.14.1 удалось устранить уязвимость jackson-databind.

### PoC для S2-055

※ Добавлено 2017-12-08

Опубликована статья с анализом S2-055 и отчёт о PoC.
* Среда для S2-055: построение и анализ | Блог NSFOCUS
  * http://blog.nsfocus.net/s2-055/

Если почитать с помощью Google Translate, кажется, что мнения совпадают относительно условий возникновения и реализуемости атаки.

Также показан PoC с HTTP-трафиком, запускающим калькулятор на модифицированном rest-showcase.

Заимствовав только часть JSON, я сначала попробовал выполнить его отдельно на Jackson. Вот пример кода:
* [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)

Если запустить его с указанием версии, использующей 2.8.8, в среде автора вывод был таким:```
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)
(...)

Здесь, в том же месяце, был выпущен 2.9.0 как дополнительное исправление для борьбы с черным списком.
* https://github.com/FasterXML/jackson-databind/issues/1680

Это было добавлено:```java
s.add("com.sun.rowset.JdbcRowSetImpl");

### 2017-август

* Выпущена версия 2.8.10, соответствующая #1680, #1737.
* Также в августе был открыт следующий Issue, и ведется комплексная работа по CVE-2017-7525.
  * https://github.com/FasterXML/jackson-databind/issues/1723
* В блоге Адама Кауделла опубликовано описание эксплуатации CVE-2017-7525.
  * https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/

### 2017-сентябрь

* Выпущена версия 2.9.1, соответствующая #1737.

### 2017-октябрь

В следующей bugzilla начинается работа над применением черного списка из последних версий 2.8.10 / 2.9.1 для CVE-2017-15095, поскольку исправления CVE-2017-7525 в версиях 2.8.9 / 2.9.0 оказались недостаточными.
* https://bugzilla.redhat.com/show_bug.cgi?id=1506612

### 2017-ноябрь

* RedHat опубликовала информацию о CVE-2017-15095.
  * https://access.redhat.com/security/cve/cve-2017-15095

* В Issue jackson-databind также ведется обсуждение статуса CVE-2017-15095.
  * https://github.com/FasterXML/jackson-databind/issues/1847
  * Ответ: исправлено в версиях 2.8.10 / 2.9.1.

### 2017-декабрь

* В блоге разработчиков облачного WAF Scutum опубликована статья с пояснениями.
  * https://www.scutum.jp/information/waf_tech_blog/2017/12/waf-blog-052.html
  * В этой статье отмечается, что в черном списке версии 2.9.3 есть недочеты, связанные с классами Spring, которые не являются критичными, но возможно, потребуется обновление.
  * Также обсуждается вопрос, лежит ли ответственность за эту уязвимость на библиотеке или на приложении.

## О будущих тенденциях уязвимостей, связанных с Java serialize/deserialize

Создается впечатление, что за последние два года количество информации об уязвимостях, связанных с Java serialize/deserialize, увеличилось.
В качестве примера, информация об уязвимостях продуктов Pivotal, включая Spring, публикуется на https://pivotal.io/security/, и в 2017 году, помимо CVE-2017-4995, были опубликованы следующие уязвимости:

* https://pivotal.io/security/cve-2017-8045
  * RCE из-за проблемы десериализации `org.springframework.amqp.core.Message` в Spring AMQP
* https://pivotal.io/security/cve-2017-8046
  * RCE из-за недостатков обработки JSON в методе PATCH в Spring Data REST

Поскольку это уязвимости, которые легко приводят к RCE, как атакующие, так и исследователи уязвимостей в настоящее время уделяют большое внимание Java serialize/deserialize.
В ближайшие несколько лет, вероятно, будут продолжаться сообщения об уязвимостях, связанных с обработкой serialize/deserialize.
Хотя Jackson не является исключением, в современной разработке, где обмен данными через удаленные API стал обычным делом, а библиотеки повышают эффективность, полный отказ от serialize/deserialize или их самостоятельная реализация с нуля на практике во многих случаях невозможны.
Лично я считаю, что ключевым моментом является создание гибкой среды разработки и культуры, позволяющей как можно быстрее обновлять библиотеки при обнаружении уязвимостей.

Поскольку у меня были мысли о том, как в будущем относиться к уязвимостям в зависимых промежуточных программных обеспечениях, библиотеках и фреймворках, я решил написать ниже свои впечатления.

## Впечатления

Когда я увидел информацию о публикации S2-054, 055 и о том, что на них влияет уязвимость Jackson, я был довольно шокирован.
Потому что несколькими днями ранее коллега спросил меня: «Какая библиотека рекомендуется для парсинга JSON на Java?», и я с гордым видом ответил: «Jackson широко используется в OSS, имеет хорошую репутацию, и в Google можно найти много статей и QA, поэтому я рекомендую его».
Я сам использовал Jackson при разработке внутренних инструментов компании и ощущал его удобство.
Однако на тот момент я не знал о CVE-2017-7525 и был полностью спокоен, потому что Jackson широко используется в OSS и имеет много пользователей.

Тут другой коллега нашел блог Адама Кауделла и рассказал мне о существовании CVE-2017-7525. Через несколько дней после того, как я с гордым видом рекомендовал Jackson, Struts2 выпустил обновление из-за уязвимости Jackson, и притом сама уязвимость Jackson была исправлена несколько месяцев назад. Как инженер, работающий в сфере безопасности, я не могу оправдаться, если меня упрекнут в том, что я пренебрег сбором информации об уязвимостях используемой мной библиотеки (хотя это действительно так).

Поэтому в последние несколько дней мое психическое состояние было ужасным (повышение артериального давления и пульса, дрожь в руках, слезы без причины, учащенное сердцебиение и т. д.). Чтобы как-то справиться, я решил для начала узнать, что такое CVE-2017-7525 и в какой ситуации находится Jackson, и провел выходные, занимаясь исследованием и написанием этой статьи.

Оглядываясь назад, я остро осознаю, что, сосредоточившись на разработке, трудно уделять внимание информации об обновлениях зависимых библиотек.
В непрерывном потоке задач разработки практически невозможно полностью изучить функциональность и качество, включая уязвимости, всех используемых библиотек.
С другой стороны, требования к разработке становятся все выше, и реализовать все самостоятельно также практически невозможно.
Где-то приходится «доверять» используемым библиотекам и повышать эффективность разработки.
Однако отслеживать информацию об обновлениях всех используемых инструментов и библиотек в повседневной разработке и следить за тем, не содержат ли они исправлений проблем безопасности, также очень сложно.
Конечно, я знаю, что для решения этой задачи существуют сервисы, которые регистрируют используемые инструменты и библиотеки и рассылают информацию об их обновлениях.

Из ухудшения своего психического состояния я понял, что у меня очень сильное «чувство вины и самообвинения за то, что не сделал».
Я навешивал на себя негативный ярлык: «Как инженер по безопасности, я не знал об уязвимости библиотеки, которую сам использовал...».
Даже обычные разработчики, не связанные с индустрией безопасности, вероятно, испытывают сожаление или беспокойство, например: «Если бы я тогда не предложил Struts2...» или «Нужно более тщательно управлять жизненным циклом библиотек/фреймворков (= я беспокоюсь о текущем положении дел, когда это не делается)».

Если попытаться «решить» эти «проблемы» в лоб, придется собирать информацию об уязвимостях по одной, проверять исходный код и функциональность планируемых к использованию библиотек и фреймворков, тщательно выяснять, можно ли их считать де-факто стандартом, а после начала эксплуатации строго управлять жизненным циклом.

Однако возможно ли в современных разнообразных условиях разработки вообще применять такой подход «перестраховщика»?

Прочитав эту статью, я подумал, что время, когда «то, что не было сделано / не было возможным сделать / не было замечено» рассматривалось как причина или виновник, а его устранение (= сделать возможным) считалось «решением проблемы», возможно, уже прошло.
В такой культуре, если только человек не идеален, разработчик будет бесконечно сталкиваться со своим «не сделанным, не сделанным, не замеченным».
Поскольку идеальных людей нет, я думаю, что без очень сильной психики это не выдержать.

В вопросах безопасности программного обеспечения реальный преступник, наносящий ущерб, — это атакующий. Ситуацию ухудшает атакующий, использующий уязвимости.

Подавляющее большинство разработчиков, как правило, добросовестно и добросовестно занимаются разработкой. На этом этапе они уже находятся в положительном состоянии.
«Отсутствие управления жизненным циклом библиотек/фреймворков» или «отсутствие сбора и мониторинга информации об уязвимостях используемых библиотек» — это просто неделание, состояние ни плюс, ни минус.
Неужели не печально, что из-за существования атакующего «не сделанное» становится «не возможным / не замеченным» и превращается в минус?

Нельзя отрицать, что на ценности «перестраховки» влияет современное японское общество и корпоративная культура.
Действительно, есть случаи, когда из-за внедрения уязвимостей, таких как SQL-инъекции, происходят атаки, и в суде рассматриваются дела о привлечении к ответственности компании-разработчика.
Бывают случаи, когда невнимательность на работе приводит к серьезным авариям.

Однако, если сводить все это к проблеме «компании-разработчика / разработчика», мне кажется, что вся IT-разработка будет парализована.
Действительно плохи — это атакующие, использующие уязвимости.
С этой точки зрения, разве разработчики и компании-разработчики, которые «не сделали / не смогли / не заметили», скорее жертвы, чем преступники?
Если так, то я strongly believe, что важно не указывать жертве: «Ты плохой, потому что не сделал / не смог / не заметил», а протянуть теплую руку, чтобы идти вместе, с целью совместного движения: «Давай сделаем это безопаснее, давай улучшим, будем стараться вместе», соревнуясь и используя друг друга в своих областях экспертизы.
Тогда компании-разработчики и разработчики смогут спокойно заниматься устранением уязвимостей, и в дальнейшем им будет легче активно развиваться на основе спокойствия.
Если разработка будет спокойной, светлой и активной, в результате увеличится количество инновационных результатов, и японское общество станет богаче, не так ли?

Лично я strongly feel, что в будущем было бы хорошо, если бы распространились следующие взгляды:

* Разработчики на местах
  * «Использование библиотеки с уязвимостью» само по себе не является минусом.
  * Минус создают атакующие, использующие уязвимости, и сама культура, оценивающая это как минус.
  * Ежедневная добросовестная работа и разработка — это уже достаточный плюс.
  * Устранение уязвимостей — это не работа по возвращению минуса к нулю, а положительная работа по улучшению ежедневных результатов разработки, делая их более безопасными.
* Менеджеры, руководители и высшее руководство, объединяющие разработчиков
  * Не оценивайте «то, что не было сделано / не было возможным сделать / не было замечено» как минус. Такая ценность будет постепенно исчезать.
  * Перестаньте обращаться с членами команды, которые «не сделали / не смогли / не заметили», как с виновными. Они, и мы все, — жертвы атакующих, использующих уязвимости, и с этой точки зрения мы на одной стороне.
  * Прекратите подход к решению «полными мерами».

Это касается изменения «взгляда на вещи / способа восприятия», вовлекая разработчиков, менеджеров, руководителей и высшее руководство, что, очевидно, очень сложно.
Как же это изменить?
У меня недостаточно сил, чтобы дать правильный ответ, но я думаю, что в этом есть одна подсказка.
А именно: возможно, сам поиск правильного ответа уже нужно прекратить.
У любой разработки программного обеспечения есть какая-то цель. Поиск «правильного ответа» для ее безопасной и защищенной реализации стал настолько сложным, что мир программного обеспечения стал слишком сложным.
Возможно, там находится парадигма разработки, основанная на «изменении», где множество игроков по-своему пробуют и ошибаются, получают обратную связь, обмениваются информацией и свободно ветвятся и изменяются.

В системной разработке созданные однажды программные активы используются в течение нескольких лет, а иногда и десятилетий.
Однако программное обеспечение, подключенное к Интернету, особенно веб-разработка, сталкивается со средой, которая меняется за несколько месяцев или лет.
Библиотеки и фреймворки, использованные при разработке 5 лет назад, могут стать непригодными.
В таком случае парадигма разработки, при которой первоначально созданные библиотеки/фреймворки считаются «правильными» и их версии «фиксируются», имеет больше недостатков.
Внешний мир постоянно меняется, поэтому обнаружение уязвимостей в используемых библиотеках/фреймворках — это обычное дело.
Если зафиксировать версии, вы не сможете идти в ногу с этими изменениями, и в результате придется платить огромные умственные и физические затраты на устранение уязвимостей.
Поэтому я strongly believe, что переход к парадигме разработки, основанной на «изменении / способности следовать за изменениями», в долгосрочной перспективе приведет к лучшим результатам.

Статья получилась длинной, но это всё.

----
Автор: Масахико Сакамото (отдел исследований и разработок, занимается разработкой инструментов диагностики веб-приложений, используемых внутри компании)
* Почта: [email protected]
* Twitter: https://twitter.com/msakamoto_sf
* Facebook: https://www.facebook.com/masahiko.sakamoto.75
* GitHub: https://github.com/msakamoto-sf

По вопросам и предложениям по данной статье обращайтесь к Сакамото.