Bei dieser Konfiguration gibt es zwei Fälle: Der Inhalt des Schlüssels "animal" zeigt entweder auf die Dog-Klasse oder auf die Cat-Klasse. Daher sind zusätzliche Informationen erforderlich, um zu bestimmen, welche Klasse für die Zuordnung verwendet werden soll.

Um dieses Problem zu lösen, hat jackson-databind eine eigene Verarbeitung integriert, die den Namen der zuzuordnenden Klasse in das JSON einbetten kann.

Zum Beispiel wie folgt, indem der Inhalt des Schlüssels "animal" in ein Array umgewandelt wird und das erste Element den Klassennamen angibt.```
{"animal":["Dog",{"name":"dog1","barkVolume":1.2}]}

In der Ausgabe gibt es eine Zeile: `at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl$1.run(TemplatesImpl.java:401)`.  
In diesem Beispielcode wird eine NullPointerException geworfen, aber der Methodenname deutet darauf hin, dass eine Verarbeitung mit Nebeneffekten stattfindet.  

Um ein JSON zu erstellen, das die Codeausführung tatsächlich erfolgreich macht, sind weitere Untersuchungen erforderlich.  
In diesem Artikel beschränken wir uns vorerst auf diese Einführung, aber wenn weitere Forschungsartikel auf anderen Websites veröffentlicht werden, möchten wir sie hier ergänzen.  

Übrigens, wo wird die wichtige Blacklist implementiert? Es ist die folgende Klasse:  
* https://github.com/FasterXML/jackson-databind/blob/jackson-databind-2.8.9/src/main/java/com/fasterxml/jackson/databind/deser/BeanDeserializerFactory.java#L51  

Tatsächlich scheint es, dass es in Version 2.8.9 eine Lücke in dieser Blacklist gab. Dieses Problem ist CVE-2017-15095.  

### Verbesserung der Blacklist durch CVE-2017-15095  

Was die Verbesserung der Blacklist-Lücke betrifft, wurde zunächst in https://github.com/FasterXML/jackson-databind/issues/1680 `s.add("com.sun.rowset.JdbcRowSetImpl");` hinzugefügt.  
Nachdem damit 2.9.0 veröffentlicht wurde, wurde in https://github.com/FasterXML/jackson-databind/issues/1737 die folgende Blacklist-Überprüfung hinzugefügt.```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` クラス名がblack listチェックをすり抜け、インスタンス化されることで実際にファイルをオープンを試みていることがわかります。
対応後のバージョンでは black listチェックで捕まり、 `JsonMappingException` 例外がthrowされています。

なお 2.8.10 時点のblacklistは以下のようになりました。`[databind#1737]` のコメントで始まっているところが、CVE-2017-15095に対応した追加のblacklistになります。
* 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()`を呼んでからdeserializeしている。
   * `ObjectMapper.enableDefaultTyping()`は呼んでいないが、クラス宣言で `@JsonTypeInfo` アノテーションを使ってマッピングできるようにして、deserializeしている。
   * アプリケーションコードで使っていなくても、フレームワーク側で `Accept` リクエストヘッダーやURLの拡張子に応じて自動でdeserializeする場合があります。
3. classpath中に、Java serialize/deserializeの脆弱性で悪用される可能性のあるクラス("Gadget")を含んでいる。
4. マッピング先のJavaクラスのメンバフィールドで、Object型などGadgetクラスを受け入れられるような型を使っている。
   * Gadgetに使われるクラスと互換性の無い、アプリケーション固有のBeanクラスなどを型としていれば、実際にインスタンスを生成する前に型チェックのエラーで弾くことができます。(アプリケーション固有のBeanクラスそれ自体にdeserializeの脆弱性が潜んでいた場合を除く)

本当に影響をうけるかどうかについては、`ObjectMapper` の使い方/設定状態や`@JsonTypeInfo` アノテーションの組み合わせ、さらにマッピング先のクラスのメンバフィールド等など、アプリケーション側のコードに大きく左右される状況のようです。

また、JSON中のキー名が、deserialize先のJavaクラスに存在しない場合、Jacksonでは単に無視されます。
そのため、攻撃を成功させるにはアプリケーションごとのJSONに合わせてカスタマイズが必要となり、複数のアプリケーションで使いまわせるような攻撃コードを作るのは非常に難しいと思われます。

さらに条件4. について、一般的な書き方であればまず、わざわざJavaクラスのフィールドを Object 型にすることは無いと思います。
任意のコード実行が可能になるクラスも、大概はアプリケーションで作り込むBeanクラスとは互換性が無い場合が大半と思われます。

以上から、大規模な攻撃が発生したり、実際にこの脆弱性を悪用して被害を発生させる(=攻撃が成功する)可能性は低いと思われます。

アプリケーション側の対応ですが、条件 3. についてはJDKに含まれるクラスも悪用可能ですので事実上対策できないものと思われます。
そのため、基本的にはjackson-databindを最新バージョンにUPすることが対策となります。
jackson-databindを最新バージョンにUPできない場合は、`ObjectMapper.enableDefaultTyping()` の呼び出しや`@JsonTypeInfo` アノテーションを削除して、それに依存しないような設計に改修することになります。例えば、カスタムでシリアライザを作成するなどが考えられます。

とはいえリモート呼び出し可能なAPIとして既に使い始めている場合、おいそれとJSONフォーマットを変更できません。
`@JsonTypeInfo` アノテーションについて、設定次第ではサブクラスを限定できるなど、プログラマが想定しているクラス名のみを受け付けられるよう設定できるようです。
詳細は以下のドキュメントをご確認ください。
* JacksonPolymorphicDeserialization
  * https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

#### black list 対策の是非とカスタムデシリアライザの作成について

jackson-databind 2.8.10 / 2.9.1 は、black list対策によりCVE-2017-7525, CVE-2017-15095 に対応しました。
しかしながら、Struts2のOGNL関連の問題で明らかなようにblack list対策は万全とは言えません。
（筆者個人としては、スキャンツールをかけるだけのいわゆる「スクリプトキディ」のレベルであればある程度実効性のある対策だと思います。）

よって本当に抜本的な対策をするのであれば、`ObjectMapper.enableDefaultTyping()` などJSONにクラス情報を埋め込み利用する機能、それ自体を無効化する/使わないことが重要と筆者は考えます。
では、そもそも `ObjectMapper.enableDefaultTyping()` が解決しようとしていた問題はどうすれば良いのか？

これについて、筆者自身も正解と言える代案は用意出来ていません。
問題の根っことしては、「マッピングするJavaクラスが曖昧なときに、信頼できないJSONに頼らずに、マッピングできること」だと思います。
それを可能にするアプローチとしては、恐らくカスタムのデシリアライザを作るアプローチがあるのではないか、と筆者は考えます。
カスタムのデシリアライザは、プログラムコード側でdeserializeの最中にJSONを受け取り、生成するObjectを自分で制御することが可能です。

例えば `{"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>` 形式にdeserializeするというやり方もあると思います。）

カスタムのデシリアライザを作るための参考記事を何点か見つけましたので、英語記事になりますがリンクを貼っておきます。
* 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/

jackson-databind の JavaDoc (2.8系, 2.9系):
* 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 自体の脆弱性について見てきました。では、実際にそれが Struts2 の REST plugin にどのように影響しているのか？ Struts2 に付属している struts2-rest-showcase を使って確認してみました。

Struts REST plugin の使い方は以下を参考にしました。
* http://struts.apache.org/plugins/rest/

### Struts2 REST plugin では ObjectMapper.enableDefaultTyping() を呼んでいない

ところで、CVE-2017-7525 で実際に脆弱となる条件として、以下の条件がありました。
* 信頼されないソースから取得したJSONについて、以下のいずれかの処理を行っている。
  * `ObjectMapper.enableDefaultTyping()`を呼んでからdeserializeしている。
  * `ObjectMapper.enableDefaultTyping()`は呼んでいないが、クラス宣言で `@JsonTypeInfo` アノテーションを使ってマッピングできるようにして、deserializeしている。

Struts2 REST plugin でこれらの条件に該当するコードがあるか確認したところ、いずれも含まれていないことが確認できました。
実際のところ、対応前の 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
  * このJavaファイルは、2.5.14.1 でも内容は変わっていません。

このため、CVE-2017-7525 に対して REST plugin それ自体は 2.5.14 の時点でも問題ない状況だったと思われます。
脆弱となるのは、アプリケーション側で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 は REST plugin を使って Order クラスのCRUDを実装したサンプルです。ここに、Jacksonの脆弱性のサンプルコードで使った Zoo / Animal / Cat / Dog クラスと、それの CRUD をJSONで処理するための ZooController などを追加してみます。

全体のソースコードは以下をご確認ください。(本記事では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 による listening ポートを 18088 に変更した。(`mvn jetty:run`)
* jackson-core, jackson-databind を依存関係に追加した。
* Zoo, Animal(abstract), Dog, Cat クラスを追加した。サービスレイヤーとして ZooService クラスを追加。
* 最低限のCRUDを備えた ZooController を追加。(ViewとなるJSPは省略した)
* struts.xml でjson用のハンドラを JacksonLibHandler に変更した。
* maven-wrapperを組み込み、JDKさえ入っていれば mvnw / mvnw.bat でそのままビルド・実行できるようにした。

ビルドと実行：
1. リポジトリを clone 後、rest-showcase ディレクトリにcdし、 `mvnw jetty:run` を実行します。(初回実行時はmavenのダウンロードが発生するため、数分～場合によっては10分以上待たされる場合がありますのでご注意ください)
1. http://localhost:18088/struts2-rest-showcase/ にアクセスし、Orderの一覧が表示されれば成功です。
1. 実行を終了するには Ctrl-C で終了できます。
1. Javaファイルを修正したら、Ctrl-Cで終了させまた `mvnw jetty:run` を実行してください。

curlコマンドでの動作確認: (local http proxy として localhost:8080 を通す前提)In der Version vor dem Patch umgeht der Klassenname `java.util.logging.FileHandler` die Blacklist-Prüfung und versucht tatsächlich, eine Datei zu öffnen, indem er instanziiert wird.
In der Version nach dem Patch wird er von der Blacklist-Prüfung abgefangen und eine `JsonMappingException` ausgelöst.

Die Blacklist zum Zeitpunkt 2.8.10 sah wie folgt aus. Der mit `[databind#1737]` beginnende Kommentar ist der zusätzliche Blacklist-Eintrag für 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

### Bedingungen für die Anfälligkeit, Realisierbarkeit eines Angriffs und Gegenmaßnahmen auf Anwendungsseite

Zusammenfassend lässt sich sagen, dass die Jackson-databind-Sicherheitslücke nur unter den folgenden Bedingungen ausgenutzt werden kann:
1. Verwendung von jackson-databind 2.8.9 / 2.9.0 oder niedriger.
2. Für JSON aus einer nicht vertrauenswürdigen Quelle wird einer der folgenden Schritte durchgeführt:
   * `ObjectMapper.enableDefaultTyping()` wird aufgerufen und dann deserialisiert.
   * `ObjectMapper.enableDefaultTyping()` wird nicht aufgerufen, aber die Klasse wird mit der Annotation `@JsonTypeInfo` versehen, um die Zuordnung zu ermöglichen, und dann deserialisiert.
   * Auch wenn es nicht im Anwendungscode verwendet wird, kann das Framework automatisch abhängig vom `Accept`-Anfrageheader oder der URL-Erweiterung deserialisieren.
3. Der Classpath enthält eine Klasse ("Gadget"), die möglicherweise durch eine Java-Serialisierungs-/Deserialisierungs-Sicherheitslücke ausgenutzt werden kann.
4. Das Zielfeld der Java-Klasse verwendet einen Typ wie Object, der eine Gadget-Klasse akzeptieren kann.
   * Wenn der Typ eine anwendungsspezifische Bean-Klasse ist, die nicht mit der für das Gadget verwendeten Klasse kompatibel ist, kann die Instanziierung durch einen Typüberprüfungsfehler verhindert werden, bevor sie tatsächlich erstellt wird. (Außer wenn die anwendungsspezifische Bean-Klasse selbst eine Deserialisierungs-Sicherheitslücke aufweist.)

Ob ein System tatsächlich betroffen ist, hängt stark vom Anwendungscode ab, einschließlich der Verwendung/Konfiguration von `ObjectMapper`, der Kombination von `@JsonTypeInfo`-Annotationen und den Zielfeldern der zugeordneten Klasse.

Wenn ein Schlüsselname im JSON in der Ziel-Java-Klasse nicht vorhanden ist, wird er von Jackson einfach ignoriert.
Daher müsste ein Angriff für jede Anwendung individuell angepasst werden, was die Erstellung eines universell einsetzbaren Angriffscodes sehr schwierig macht.

Darüber hinaus ist es bei üblicher Codierung unwahrscheinlich, dass ein Java-Klassenfeld absichtlich als Object-Typ deklariert wird.
Auch die Klassen, die eine beliebige Codeausführung ermöglichen, sind in den meisten Fällen nicht mit den anwendungsspezifischen Bean-Klassen kompatibel.

Daher ist die Wahrscheinlichkeit eines großflächigen Angriffs oder eines erfolgreichen Schadens durch Ausnutzung dieser Sicherheitslücke gering.

Auf Anwendungsseite kann Bedingung 3 nicht effektiv behoben werden, da auch Klassen aus dem JDK ausgenutzt werden können.
Daher besteht die grundlegende Gegenmaßnahme darin, jackson-databind auf die neueste Version zu aktualisieren.
Falls dies nicht möglich ist, müssen Aufrufe von `ObjectMapper.enableDefaultTyping()` und die `@JsonTypeInfo`-Annotation entfernt und das Design entsprechend angepasst werden, z. B. durch die Erstellung eines benutzerdefinierten Deserializers.

Wenn die API jedoch bereits als remote-aufrufbar genutzt wird, kann das JSON-Format nicht einfach geändert werden.
Die `@JsonTypeInfo`-Annotation kann so konfiguriert werden, dass nur vom Programmierer erwartete Unterklassen akzeptiert werden.
Weitere Details finden Sie in der folgenden Dokumentation:
* JacksonPolymorphicDeserialization
  * https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization

#### Vor- und Nachteile der Blacklist-Gegenmaßnahme und Erstellung eines benutzerdefinierten Deserializers

jackson-databind 2.8.10 / 2.9.1 behebt CVE-2017-7525 und CVE-2017-15095 durch eine Blacklist-Strategie.
Allerdings sind Blacklist-Ansätze – wie die OGNL-Probleme in Struts2 zeigen – nicht narrensicher.
(Aus persönlicher Sicht des Autors ist die Blacklist für sogenannte "Script-Kiddie"-Angriffe, die nur Scan-Tools verwenden, einigermaßen wirksam.)

Daher ist der Autor der Meinung, dass eine wirklich grundlegende Lösung darin besteht, Funktionen wie `ObjectMapper.enableDefaultTyping()`, die Klasseninformationen in JSON einbetten, zu deaktivieren oder nicht zu verwenden.
Wie sollte dann das Problem gelöst werden, das `ObjectMapper.enableDefaultTyping()` ursprünglich lösen sollte?

Der Autor hat selbst keine endgültige Antwort auf diese Frage.
Das Kernproblem ist: "Wie kann ein Java-Klassen-Mapping durchgeführt werden, wenn die Zielklasse mehrdeutig ist, ohne sich auf nicht vertrauenswürdiges JSON zu verlassen?"
Ein möglicher Ansatz wäre die Erstellung eines benutzerdefinierten Deserializers.
Ein benutzerdefinierter Deserializer ermöglicht es, das JSON während der Deserialisierung im Programmcode zu empfangen und das zu erstellende Objekt selbst zu steuern.

Zum Beispiel könnte bei Eingabe von `{"animal":{"name":"dog1","barkVolume":1.2}}` entschieden werden: "Da der Schlüssel `barkVolume` vorhanden ist, wird dies als Instanz der Dog-Klasse erstellt."
Bei `{"animal":{"name":"cat1","likesCream":true,"lives":10}}` könnte entschieden werden: "Da die Schlüssel `likesCream` und `lives` vorhanden sind, wird dies als Instanz der Cat-Klasse erstellt."
Dadurch wird es unnötig, den Klassennamen explizit in JSON einzubetten.

Persönlich habe ich den Eindruck, dass das Einbetten von Klassennamen in JSON die Interoperabilität mit anderen Sprachen/Bibliotheken beeinträchtigt (falls jemand ähnliche Erweiterungen in anderen Sprachen/Bibliotheken kennt, bitte teilen).
Wenn die Interoperabilität mit anderen Systemen wichtig ist, scheint es sinnvoller, einen benutzerdefinierten Deserializer in Jackson zu erstellen, als andere zu zwingen, proprietäre Klassennamen in JSON einzubetten.

Es gibt wahrscheinlich auch andere Lösungsansätze. Wenn Leser eine andere Lösung vorschlagen möchten, freue ich mich über Kommentare.
(Als extremes Beispiel könnte man alles in `Map<String, Object>` oder `List<String, Object>` deserialisieren, anstatt es einer bestimmten Klasse zuzuordnen.)

Hier sind einige englischsprachige Artikel zur Erstellung eines benutzerdefinierten Deserializers:
* 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 für 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/

Der Autor hat auch einen Beispielcode für einen benutzerdefinierten Deserializer erstellt, der als Anregung dienen kann:
* [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)

## Über S2-055

Bislang haben wir uns die Sicherheitslücke in Jackson selbst angesehen. Wie wirkt sich diese nun tatsächlich auf das REST-Plugin von Struts2 aus? Dies wurde mit der Struts2-Beispielanwendung struts2-rest-showcase überprüft.

Die Verwendung des Struts REST-Plugins wurde hier beschrieben:
* http://struts.apache.org/plugins/rest/

### Das Struts2 REST-Plugin ruft ObjectMapper.enableDefaultTyping() nicht auf

Bei CVE-2017-7525 gab es folgende Bedingungen für die tatsächliche Anfälligkeit:
* Für JSON aus einer nicht vertrauenswürdigen Quelle wird einer der folgenden Schritte durchgeführt:
  * `ObjectMapper.enableDefaultTyping()` wird aufgerufen und dann deserialisiert.
  * `ObjectMapper.enableDefaultTyping()` wird nicht aufgerufen, aber die Klasse wird mit der Annotation `@JsonTypeInfo` versehen, um die Zuordnung zu ermöglichen, und dann deserialisiert.

Bei der Überprüfung, ob das Struts2 REST-Plugin Code enthält, der diese Bedingungen erfüllt, wurde festgestellt, dass keiner dieser Fälle zutrifft.
Tatsächlich wurde zum Zeitpunkt der Version 2.5.14 vor dem Patch weder `ObjectMapper.enableDefaultTyping()` noch `@JsonTypeInfo` im REST-Plugin oder im gesamten Struts2-Quellbaum verwendet, wie ein grep ergab.
* https://github.com/apache/struts/tree/STRUTS_2_5_14

Im gesamten Struts2-Quellbaum verwendet nur die Klasse `org.apache.struts2.rest.handler.JacksonLibHandler` Jacksons `ObjectMapper`. Die Überprüfung des Quellcodes zeigt, dass in Version 2.5.14 tatsächlich `ObjectMapper.enableDefaultTyping()` nicht verwendet wird.
* https://github.com/apache/struts/blob/STRUTS_2_5_14/plugins/rest/src/main/java/org/apache/struts2/rest/handler/JacksonLibHandler.java
  * Diese Java-Datei unterscheidet sich auch in Version 2.5.14.1 nicht.

Daher war das REST-Plugin an sich bezüglich CVE-2017-7525 selbst in Version 2.5.14 vermutlich nicht anfällig.
Die Anfälligkeit besteht nur, wenn die Anwendung in den Feldern der JSON-zugeordneten Klasse `@JsonTypeInfo` setzt.
Daher wird in der folgenden Überprüfung mit struts2-rest-showcase in den zusätzlich zur Anwendung hinzugefügten Zielfeldern `@JsonTypeInfo` gesetzt.

Übrigens gibt es in Struts2 auch ein JSON-Plugin.
* http://struts.apache.org/plugins/json/
* Bei der Überprüfung des Quellcodes des JSON-Plugins fällt auf, dass `pom.xml` keine anderen JSON-Bibliotheken als Abhängigkeiten enthält.
* Offenbar implementiert es die JSON-Verarbeitung selbst.
* https://github.com/apache/struts/tree/STRUTS_2_5_14/plugins/json
* Daher betrifft die Jackson-databind-Sicherheitslücke das JSON-Plugin vermutlich nicht.

### Jackson-Kompatibilität für struts2-rest-showcase

struts2-rest-showcase ist ein Beispiel, das CRUD für die Order-Klasse mithilfe des REST-Plugins implementiert. Hier fügen wir die Klassen Zoo / Animal / Cat / Dog hinzu, die im Beispielcode für die Jackson-Sicherheitslücke verwendet wurden, sowie einen ZooController für die JSON-basierte CRUD-Verarbeitung.

Der gesamte Quellcode ist unten zu finden. (In diesem Artikel wurde die Erstellung und Ausführung mit JDK8 getestet.)
* [rest-showcase](https://github.com/SecureSkyTechnology/study-struts2-s2-054_055-jackson-cve-2017-7525_cve-2017-15095/tree/master/rest-showcase)

Wesentliche Änderungen:
* Der Listening-Port des jetty-maven-plugin wurde auf 18088 geändert. (`mvn jetty:run`)
* jackson-core und jackson-databind wurden als Abhängigkeiten hinzugefügt.
* Die Klassen Zoo, Animal (abstrakt), Dog, Cat wurden hinzugefügt. Die Dienstschicht-Klasse ZooService wurde hinzugefügt.
* Ein ZooController mit minimalen CRUD-Funktionen wurde hinzugefügt. (Die View-JSPs wurden weggelassen.)
* In struts.xml wurde der Handler für JSON auf JacksonLibHandler geändert.
* Maven-Wrapper wurde integriert, sodass das Projekt mit `mvnw` / `mvnw.bat` gebaut und ausgeführt werden kann, sofern JDK installiert ist.

Build und Ausführung:
1. Nach dem Klonen des Repositories in das Verzeichnis rest-showcase wechseln und `mvnw jetty:run` ausführen. (Beachten Sie, dass beim ersten Lauf Maven-Downloads erfolgen, was einige Minuten bis zu über 10 Minuten dauern kann.)
1. Rufen Sie http://localhost:18088/struts2-rest-showcase/ auf. Wenn die Liste der Orders angezeigt wird, war die Ausführung erfolgreich.
1. Beenden Sie die Ausführung mit Strg-C.
1. Nach Änderungen an Java-Dateien beenden Sie die Ausführung mit Strg-C und führen erneut `mvnw jetty:run` aus.

Überprüfung mit curl-Befehl: (unter der Annahme, dass localhost:8080 als lokaler HTTP-Proxy genutzt wird)```
一覧取得:
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

Hier senden wir eine JSON-Anfrage mit der POST-Methode und rufen die Methode ZooController.create() auf.```
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}}'

Dann heben Sie das Auskommentieren von `@JsonTypeInfo` im `animal`-Feld auf, um es zu aktivieren. Stoppen Sie die Webanwendung mit Ctrl-C und führen Sie erneut `mvnw jetty:run` aus.```java
// 次のimportを忘れずに追加
import com.fasterxml.jackson.annotation.JsonTypeInfo;
//...
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    public Animal animal;
    //public Object animal;

→ Es wird `HTTP/1.1 201 Created` zurückgegeben. Wenn man die Liste abruft, kann man bestätigen, dass sie tatsächlich hinzugefügt wurde.

### Überprüfung von CVE-2017-7525 im Struts2 REST plugin 2.5.14

In der pom.xml des Repositorys wird im `<parent>`-Artifact von Struts die Version 2.5.14 angegeben, daher ist es ohne weitere Maßnahmen anfällig für CVE-2017-7525. Um dies zu überprüfen, führen Sie den folgenden curl-Befehl aus. Der Klassenname und dessen Inhalt basieren auf der Datei `cve-2017-7525-check.groovy`. Wenn die gleiche Reaktion wie bei jackson-databind 2.8.8 zurückgegeben wird, gilt das System als anfällig.```
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":{}}]}'

Es scheint, dass eine IllegalArgumentException aufgetreten ist, weil der Typ des `animal`-Felds die Klasse Animal ist, die kein Subtyp der Klasse com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl ist.

Also ändern wir das `animal`-Feld in Zoo.java in den Typ Object und führen es erneut mit `mvnw jetty:run` aus.```java
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    //public Animal animal;
    public Object animal;

これは cve-2017-7525-check.groovy で検証した時と同じ、脆弱な場合の例外です。

Daraus ergibt sich, dass im Struts2 REST-Plugin 2.5.14 die Schwachstelle CVE-2017-7525 von jackson-databind bestätigt wurde.

Außerdem wurde festgestellt, dass zusätzlich zu `@JsonTypeInfo` die Verwendung des Typs Object erforderlich ist.

Im Folgenden meine persönliche Meinung: Es erscheint nicht allgemein üblich, in Datenklassen für REST-APIs als Feldtypen bewusst die Klasse Object oder Klassen zu verwenden, die mit als Gadget nutzbaren Klassen in Java-Deserialisierungsschwachstellen kompatibel sind. Daher halte ich es für schwierig, einen Angriff tatsächlich erfolgreich durchzuführen.

### Überprüfung der Behebung im Struts2 REST-Plugin 2.5.14.1

Nun wollen wir überprüfen, ob die Schwachstelle in Version 2.5.14.1 behoben wurde.

Ändern Sie die Version des `<parent>`-Artifakts in der pom.xml auf 2.5.14.1, starten Sie mit `mvnw jetty:run` neu und führen Sie den gleichen curl-Befehl wie zuvor aus.```
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":{}}]}'

Dies ist die gleiche Ausnahme wie bei der Überprüfung mit cve-2017-7525-check.groovy, nachdem die Sicherheitslücke behoben wurde.

Wenn Sie es in einer Maven-kompatiblen IDE wie Eclipse öffnen und die Version von jackson-databind nach Auflösung der Abhängigkeiten überprüfen, können Sie bestätigen, dass sie tatsächlich 2.9.2 ist. Falls Sie keine IDE haben, können Sie mit `mvnw help:effective-pom` die endgültige pom ausgeben lassen und dort nach jackson-databind suchen, um zu bestätigen, dass Version 2.9.2 verwendet wird.

Ich lasse CVE-2017-15095 aus, aber wie oben gezeigt, konnten wir bestätigen, dass die Sicherheitslücke in jackson-databind mit Version 2.5.14.1 behoben wurde.

### PoC für S2-055

※ 2017-12-08 Nachtrag

Ein Forschungsartikel und ein PoC-Bericht zu S2-055 wurden veröffentlicht.
* S2-055漏洞环境搭建与分析 | 绿盟科技博客
  * http://blog.nsfocus.net/s2-055/

Wenn ich es mit Hilfe von Google Translate lese, scheint es die gleiche Meinung zu den Entstehungsbedingungen und der Realisierbarkeit des Angriffs zu geben.

Tatsächlich wurde das rest-showcase modifiziert und ein PoC für die HTTP-Kommunikation, die einen Taschenrechner startet, gezeigt.

Ich habe nur den JSON-Teil übernommen und zunächst mit Jackson allein getestet, und der folgende Beispielcode zeigt dies:
* [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)

Wenn ich es hier mit der angegebenen Version 2.8.8 ausführe, erhalte ich in meiner Umgebung die folgende Ausgabe:```
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)
(...)

Hier wurde im selben Monat als zusätzlicher Fix für die Black-List-Gegenmaßnahme die Version 2.9.0 veröffentlicht.  
* https://github.com/FasterXML/jackson-databind/issues/1680  

Dies wurde hinzugefügt:```java
s.add("com.sun.rowset.JdbcRowSetImpl");

### 2017-08

* Version 2.8.10 veröffentlicht, die #1680, #1737 adressiert.
* Im August wurden weitere Issues eröffnet und die Behandlung als CVE-2017-7525 umfassend diskutiert.
  * https://github.com/FasterXML/jackson-databind/issues/1723
* Adam Caudill hat in seinem Blog einen Exploit-Artikel zu CVE-2017-7525 veröffentlicht.
  * https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/

### 2017-09

* Version 2.9.1 veröffentlicht, die #1737 adressiert.

### 2017-10

Im folgenden Bugzilla begann die Arbeit, die Blacklist der neuesten Versionen 2.8.10 / 2.9.1 anzuwenden, da die zum Zeitpunkt der Behebung von CVE-2017-7525 vorliegenden Versionen 2.8.9 / 2.9.0 nicht ausreichend waren und nun als CVE-2017-15095 geführt wurde.
* https://bugzilla.redhat.com/show_bug.cgi?id=1506612

### 2017-11

* RedHat veröffentlichte Informationen zu CVE-2017-15095.
  * https://access.redhat.com/security/cve/cve-2017-15095

* Auch im Issue von jackson-databind wurde die Behandlung von CVE-2017-15095 diskutiert.
  * https://github.com/FasterXML/jackson-databind/issues/1847
  * Es wurde geantwortet, dass die Behebung in 2.8.10 / 2.9.1 erfolgt sei.

### 2017-12

* Ein erklärender Artikel wurde im Entwicklerblog des Cloud-basierten WAF Scutum veröffentlicht.
  * https://www.scutum.jp/information/waf_tech_blog/2017/12/waf-blog-052.html
  * In diesem Artikel wird darauf hingewiesen, dass in der Blacklist von 2.9.3 ein Fehler bei einer Spring-Klasse besteht, der zwar nicht sofort zu einem Problem führt, aber möglicherweise ein weiteres Update erforderlich macht.
  * Zudem wird diskutiert, ob die Verantwortung für diese Schwachstelle überhaupt bei der Bibliothek lag oder nicht doch eher bei der Anwendung.

## Zukünftige Trends bei Java-Serialisierungs-/Deserialisierungsschwachstellen

Seit etwa zwei Jahren habe ich den Eindruck, dass die Anzahl der Sicherheitsmeldungen im Zusammenhang mit Java-Serialisierung/Deserialisierung zunimmt.
Ein Beispiel: Sicherheitsinformationen zu Pivotal-Produkten (einschließlich Spring) werden unter https://pivotal.io/security/ veröffentlicht. Tatsächlich wurden im Jahr 2017 zusätzlich zu CVE-2017-4995 die folgenden Sicherheitsmeldungen veröffentlicht:

* https://pivotal.io/security/cve-2017-8045
  * RCE durch Deserialisierung von `org.springframework.amqp.core.Message` in Spring AMQP
* https://pivotal.io/security/cve-2017-8046
  * RCE aufgrund einer fehlerhaften JSON-Behandlung bei der PATCH-Methode in Spring Data REST

Da es sich um Schwachstellen handelt, die leicht zu RCE führen können, scheinen sowohl Angreifer als auch Sicherheitsforscher derzeit besonders auf die Java-Serialisierung/Deserialisierung zu achten.
Ich gehe davon aus, dass die Meldungen zu Schwachstellen im Zusammenhang mit Serialisierungs-/Deserialisierungsprozessen auch in den nächsten Jahren anhalten werden.
Allerdings ist es in der heutigen Entwicklung, die durch Remote-APIs den Datenaustausch erleichtert und bei der Bibliotheken wie Jackson die Arbeit beschleunigen, in vielen Projekten kaum realistisch, auf Serialisierung/Deserialisierung gänzlich zu verzichten oder sie von Grund auf selbst zu implementieren.
Ich persönlich glaube, dass es wichtiger ist, eine agile Entwicklungskultur und -umgebung zu schaffen, die es ermöglicht, Bibliotheken möglichst schnell zu aktualisieren, sobald Schwachstellen bekannt werden.

Da ich selbst Gedanken zur mentalen Einstellung im Umgang mit Schwachstellen in Abhängigkeiten (Middleware, Bibliotheken, Frameworks) hatte, möchte ich diese im Folgenden als persönliche Reflexion teilen.

## Gedanken

Als ich die Informationen zu S2-054 und 055 sah, die auf Schwachstellen in Jackson zurückgehen, war ich ziemlich schockiert.
Nur wenige Tage zuvor hatte mich ein Kollege gefragt, welche Bibliothek ich für das JSON-Parsing in Java empfehlen würde. Ich hatte mit stolzer Miene geantwortet: „Jackson ist weit verbreitet, hat sich bewährt, und man findet viele Artikel und Q&A dazu – sehr zu empfehlen.“

Ich selbst nutze Jackson in internen Tool-Entwicklungen und schätze seine Nützlichkeit.
Zu diesem Zeitpunkt kannte ich CVE-2017-7525 jedoch nicht und war allzu sorglos, weil Jackson so weit verbreitet und von vielen genutzt wird.

Ein anderer Kollege fand dann Adam Caudills Blog und machte mich auf CVE-2017-7525 aufmerksam. Nur wenige Tage, nachdem ich Jackson mit stolzer Miene empfohlen hatte, wurde ein Update für Struts2 aufgrund der Jackson-Schwachstelle veröffentlicht – und das, obwohl die Schwachstelle in Jackson selbst bereits seit Monaten behoben war. Als Ingenieur in der Sicherheitsbranche hätte ich mich nicht herausreden können, wenn man mir vorgeworfen hätte, die Sammlung von Sicherheitsinformationen über die von mir genutzte Bibliothek vernachlässigt zu haben (was ja auch der Fall war).

Infolgedessen war mein mentaler Zustand in den folgenden Tagen extrem schlecht (erhöhter Blutdruck und Puls, zitternde Hände, tränende Augen ohne Traurigkeit, anhaltende Herzklopfen). Um dem entgegenzuwirken, begann ich, das Wochenende zu nutzen, um zu recherchieren und diesen Artikel zu schreiben – um zuerst zu verstehen, was CVE-2017-7525 ist und wie die Situation bei Jackson wirklich aussieht.

Rückblickend wird mir schmerzlich bewusst, wie schwierig es ist, während der Konzentration auf die Entwicklung auch noch die Update-Informationen zu abhängigen Bibliotheken im Auge zu behalten.
In der ständigen Flut von Entwicklungsaufgaben ist es praktisch unmöglich, die vollständigen Funktionen und Qualitätsaspekte (einschließlich Schwachstellen) aller verwendeten Bibliotheken zu prüfen.
Gleichzeitig werden die Anforderungen an die Entwicklung immer umfangreicher, und es ist ebenso unrealistisch, alles selbst zu entwickeln.
Irgendwann muss man den verwendeten Bibliotheken „vertrauen“, um die Entwicklung effizient zu gestalten.
Dennoch ist es äußerst schwierig, im täglichen Entwicklungsbetrieb alle Update-Informationen zu den verwendeten Tools und Bibliotheken zu verfolgen und darauf zu achten, ob Sicherheitskorrekturen enthalten sind.
Ich bin mir bewusst, dass es heutzutage Dienste gibt, die über Updates informieren, wenn man die verwendeten Tools und Bibliotheken registriert – um dieses Problem zu lösen.

Was ich durch meine eigene Verschlechterung des mentalen Zustands gelernt habe: Ich hatte ein starkes Gefühl von Selbstvorwürfen und Schuld wegen der Dinge, die ich nicht getan hatte.
Ich habe mir selbst das negative Etikett verpasst: „Obwohl ich Sicherheitsingenieur bin, habe ich die Sicherheitsinformationen zu der von mir verwendeten Bibliothek nicht gekannt …“
Auch bei normalen Entwicklern, die nicht direkt mit der Sicherheitsbranche verbunden sind, gibt es vielleicht viele, die mit Bedauern und Unruhe kämpfen, wie:
„Hätte ich nur nicht Struts2 vorgeschlagen …“ oder „Ich muss das Lebenszyklusmanagement der Bibliotheken/Frameworks viel besser machen (= ich mache mir Sorgen um meine jetzige Situation, in der ich es nicht tue)“.

Wenn man versucht, diese als „Herausforderungen“ direkt „zu lösen“, müsste man konsequent Sicherheitsinformationen sammeln, den Quellcode und die Funktionen der geplanten Bibliotheken und Frameworks im Detail prüfen, sorgfältig abwägen, ob sie als De-facto-Standard gelten, und nach der Einführung ein striktes Lebenszyklusmanagement betreiben.

Aber ist ein so vorsichtiger Ansatz („Erst die Brücke prüfen, dann überqueren“) in der heutigen vielfältigen Entwicklungslandschaft überhaupt möglich?

Beim Schreiben dieses Artikels ist mir der Gedanke gekommen, dass die Zeit vielleicht vorbei ist, in der man „Dinge, die man nicht getan/geschafft/bemerkt hat“ als Ursache oder Täter betrachtet und deren Beseitigung (also das „in die Lage versetzen, es zu tun“) als alleinige „Lösung des Problems“ ansieht.
In einer solchen Kultur müssten Entwickler, sofern sie nicht perfekt sind, ständig mit dem konfrontiert sein, was sie „nicht getan, nicht geschafft, nicht bemerkt haben“.
Da niemand perfekt ist, halte ich das für kaum durchhaltbar, es sei denn, man ist mental extrem stark.

Bei Softwaresicherheitsproblemen sind die wahren Täter, die tatsächlichen Schaden verursachen, die Angreifer. Es sind die Angreifer, die die Situation ins Negative ziehen, indem sie Schwachstellen ausnutzen.

Die überwiegende Mehrheit der Entwickler arbeitet im Grunde gutgläubig und ernsthaft an der Entwicklung. Das ist an sich bereits ein positiver Zustand.
„Kein Lebenszyklusmanagement von Bibliotheken/Frameworks zu betreiben“ oder „keine Sicherheitsinformationen über die verwendeten Bibliotheken zu sammeln und zu überwachen“ bedeutet lediglich, dass man es nicht tut – es ist weder positiv noch negativ.
Und doch wird durch die Existenz von Angreifern das „Nicht-getan-Haben“ zu einem „Nicht-geschafft/Nicht-bemerkt-Haben“, das negativ bewertet wird – ist das nicht eine traurige Situation?

Der Einfluss der modernen japanischen Gesellschaft und Unternehmenskultur auf die Wertvorstellung des „Erst die Brücke prüfen, dann überqueren“ ist nicht von der Hand zu weisen.
Tatsächlich gibt es unzählige Fälle, in denen Schwachstellen wie SQL-Injection eingebaut wurden und Angreifer Schaden anrichteten, und es gibt auch Beispiele, bei denen Entwicklungsfirmen vor Gericht zur Verantwortung gezogen wurden.
Es gibt auch Fälle, in denen Fahrlässigkeit im Beruf zu schwerwiegenden Unfällen führte.

Wenn man jedoch all dies als Problem der „Entwicklungsfirma/des Entwicklers“ betrachtet, könnte dies die gesamte IT-Entwicklung verängstigen.
Die wirklich Bösen sind die Angreifer, die Schwachstellen ausnutzen.
Aus dieser Perspektive sind Entwickler und Entwicklungsfirmen, die „es nicht getan/nicht geschafft/nicht bemerkt haben“, doch eher Opfer als Täter, oder?
Wenn dem so ist, sollten wir diesen Opfern nicht vorwerfen: „Du bist schuld, weil du es nicht getan/nicht geschafft/nicht bemerkt hast“, sondern ihnen eine helfende Hand reichen mit dem Ziel, gemeinsam voranzukommen: „So wird es sicherer, wir können uns verbessern – lass es uns gemeinsam versuchen.“ Und dann sollten wir uns in unseren jeweiligen Fachgebieten gegenseitig herausfordern und ergänzen. Das halte ich für äußerst wichtig.
Dann könnten Entwicklungsfirmen/Entwickler beruhigt an die Schwachstellenbehandlung herangehen und danach leichter eine aktive Entwicklung auf der Basis von Vertrauen betreiben.
Wenn die Entwicklungsumgebung sicher und positiv wird und aktive Entwicklung zunimmt, könnte dies zu mehr innovativen Ergebnissen führen und die japanische Gesellschaft insgesamt bereichern.

Persönlich wünsche ich mir sehr, dass sich in Zukunft die folgenden Denkweisen verbreiten:

* Entwickler vor Ort
  * „Ich habe eine Bibliothek mit Schwachstelle verwendet“ – das an sich ist nichts Negatives.
  * Negativ sind die Angreifer, die Schwachstellen ausnutzen, sowie die Kultur, die dies negativ bewertet.
  * Die tägliche ernsthafte Arbeit an der Entwicklung ist bereits ein ausreichend positiver Faktor.
  * Die Behandlung von Schwachstellen ist keine Aufgabe, um Negatives auf Null zurückzusetzen, sondern eine positive Tätigkeit, um die täglichen Entwicklungsergebnisse sicherer zu machen.
* Manager, Führungskräfte und Geschäftsleitung, die Entwickler zusammenfassen
  * Bewerten Sie „Dinge, die nicht getan/geschafft/bemerkt wurden“ nicht negativ. Eine solche Denkweise sollte allmählich verschwinden.
  * Hören Sie auf, Teammitglieder, die „es nicht getan/geschafft/bemerkt haben“, als Täter zu behandeln. Sie – und wir alle – sind Opfer der Angreifer, die Schwachstellen ausnutzen – aus dieser Perspektive sind wir in der gleichen Lage.
  * Hören Sie auf, Lösungen durch „vollständige Maßnahmen“ zu erzwingen.

Das klingt danach, dass man Entwickler, Manager, Führungskräfte und sogar die Geschäftsleitung einbeziehen müsste, um „die Sichtweise und Herangehensweise an Dinge zu ändern“ – und es ist offensichtlich, dass dies äußerst schwierig ist.
Wie könnte man es überhaupt ändern?
Ich selbst bin nicht in der Lage, die richtige Antwort zu geben, aber ich denke, darin liegt ein Hinweis.
Nämlich: Vielleicht müssen wir die Suche nach der richtigen Antwort selbst aufgeben.
Jede Softwareentwicklung hat ein bestimmtes Ziel. Die Suche nach der „richtigen Antwort“, um dieses Ziel sicher und auf sichere Weise zu erreichen, ist heute möglicherweise unmöglich geworden – die Softwarewelt ist zu komplex.
Ich habe das Gefühl, dass es sich eher um ein Entwicklungsparadigma handelt, das von vielen Akteuren geprägt ist, die auf ihre eigene Weise trial-and-error betreiben, Feedback erhalten, Informationen austauschen und von dort aus flexibel verzweigen und verändern – ein Paradigma, das „Veränderung“ voraussetzt.

In der Systementwicklung werden einmal erstellte Software-Assets oft über Jahre, manchmal Jahrzehnte genutzt.
Software, die mit dem Internet verbunden ist – insbesondere in der Webentwicklung – wird jedoch innerhalb von Monaten bis Jahren mit sich verändernden Umgebungen konfrontiert.
Bibliotheken und Frameworks, die man vor fünf Jahren verwendete, könnten heute unbrauchbar sein.
In einem Entwicklungsparadigma, das die ursprünglich verwendeten Bibliotheken/Frameworks als „richtige Lösung“ betrachtet und die Version „einfriert“, überwiegen daher die Nachteile.
Da sich die Außenwelt ständig verändert, ist es heute normal, dass in den verwendeten Bibliotheken/Frameworks Schwachstellen gefunden werden.
Wenn man die Version einfriert, kann man diesen Veränderungen nicht folgen und zahlt am Ende einen enormen mentalen und physischen Preis für die Schwachstellenbehandlung.
Daher bin ich fest davon überzeugt, dass ein Wandel hin zu einem Entwicklungsparadigma, das „Veränderung“ und „Anpassungsfähigkeit an Veränderungen“ voraussetzt, langfristig zu besseren Ergebnissen führen wird.

Das war ein langer Text. Ende.

----
Verfasser: Masahiko Sakamoto (Mitglied der Forschungs- und Entwicklungsabteilung, beschäftigt mit der Entwicklung von internen Webanwendungs-Diagnosetools u.Ä.)
* E-Mail: [email protected]
* Twitter: https://twitter.com/msakamoto_sf
* Facebook: https://www.facebook.com/masahiko.sakamoto.75
* GitHub: https://github.com/msakamoto-sf

Bei Fragen oder Anmerkungen zu diesem Artikel wenden Sie sich bitte an Sakamoto.