シリアライズは使うべきでない
- シリアライズは脆弱でリモートコード実行(RCE)やDoS攻撃などの攻撃の弱点となってしまうから
代替手段としてはJSONやProtobufなどのような他の手段を使うべし
- データフォーマットが定まっていてシリアライズよりましだから？
  - XML bombもある。Jsonハイジャックもある。
  - ユーザコードを叩くかどうかの違い？
シリアライズが避けられない場合でも、信頼できないデータはデシリアライズするべきでない
- 信頼できないデータは攻撃対象となっている可能性があるから
シリアライズが避けられないかつ信頼できないデータをデシリアライズしなければならない場合は、フィルタリングをするべし

1.2. シリアライズの脆弱性

シリアライズは脆弱である
- 理由
  - Apache Commons Collectionsの脆弱性解説 (1/3)：CodeZine（コードジン）
  - 安全でないデシリアライゼーション(Insecure Deserialization)入門 | 徳丸浩の日記
ガジェット、ガジェットチェーンによって任意のネイティブコードが実行できてしまうことがある
- Javaのシリアライズ可能な型を持つメソッドをガジェット、ガジェットの組み合わせをガジェットチェーンとよぶ
- 実際にガジェットチェーンを用いて任意のネイティブコードが実行する実証実験された
  - 主要Javaアプリケーションサーバに影響するJavaライブラリの脆弱性を正しく理解する | トレンドマイクロセキュリティブログ
  - GitHub - frohoff/ysoserial: A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.
    - Spring 4.1.4でも実証実験された
デシリアライゼーションボムによってDoS攻撃ができてしまうことがある
- デシリアライゼーションボムは、インスタンスのディシリアライズをする場合に、そのフィールドや要素のハッシュコードを計算する必要があることを悪用して、例えば深い入れ子構造になっているHashSetインスタンスなどを作成してデシリアライズさせることで、莫大な計算時間を掛けさせる攻撃手法

1.3. デシリアライズ時のフィルタリング

デシリアライズ時のフィルタリングにはObjectInputFilter (Java SE 11 & JDK 11 )を使うべし
- ホワイトリスト
- Java 9から導入されたが、6,7,8にもバックポートされている
  - オブジェクトのデシリアライゼーションフィルタがJava 9からバックポートされる

1.4. 余談

シリアライズの扱いずらさ
- 送信元と送信先が同じオブジェクトを持たなければならない
どういう局面でシリアライズを使うでしょうか
- セッション
- システム内通信
  - EJB(Enterprise Java Bean)
    - EJBとは？という方はこちら

2. 項目 86 Serializable を細心の注意を払って実装する

2.1. 結論

Serializableインターフェースは軽く考えて実装するべきではない
- 以下の3つのコストがかかってしまうから
  - リリース後のクラスの実装の変更に対する柔軟性の低下
  - バグやセキュリティホールの可能性の増大
  - テストの負荷の増大
継承するために設計されたクラスとインタフェースではSerializableを実装・拡張するべきでない
- サブクラスの実装に手間がかかるから

2.2. Serializable実装に伴う3つのコスト

2.2.1. リリース後のクラスの実装の変更に対する柔軟性の低下

Serializableを実装したクラスを一旦リリースしてしまうと、その実装を変更することは容易ではない
- クラスをシリアライズ可能にすると、そのシリアライズ形式がクラスの公開APIの一部となり、シリアライズ形式を永久にサポートし続ける必要があるから
  - デフォルトのシリアライズ形式の場合は、 privateフィールドも公開されてしまう
- serialVersionUIDを明示的に指定しない場合は、コンパイラはクラス名やクラスが実装しているインタフェース名、publicとprotectedのメンバからserialVersionUIDを生成されるするので、メソッドを一つ追加しただけでserialVersionUIDが変更され、互換性が失われるから。
  - javaバージョンによって生成されるserialVersionUIDが違う可能性あり。だから指定しましょう

2.2.2. バグやセキュリティホールの可能性の増大

バグの可能性が増大する理由は、デシリアライズ時のオブジェクトは通常のコンストラクタを使わずに生成されるため、コンストラクタで保証される不変式が保証されないから。
セキュリティホールについては、項目85参照

2.2.3. テストの負荷の増大

新たなリリースのインスタンスをシリアライズし、古いリリースのデシリアライズ処理でインスタンスが復元できるを確認する必要がある。また逆に、古いリリースのインスタンスをシリアライズし、新しいリリースのデシリアライズ処理で復元できるかも確認する必要がある
これらのテストは、新旧のインスタンス間でシリアライズ/デシリアライズできるかというバイナリ互換性に加えて、動作が意図しているものかどうかというセマンティクス互換性も検査する必要がある
- 互換の一覧
  - ソース互換
    - ソースをコンパイルできる
  - バイナリ互換
    - バイナリを実行できる
  - 動作の互換性（≒セマンティクス互換性）
    - 動作が同じ

2.2.4. 継承するために設計されたクラス・インターフェースに対するSerializable実装

継承するために設計されたクラスとインタフェースではSerializableを実装・拡張するべきでない
- サブクラスの実装に手間がかかるから
ただし上記には例外があり、「例えば、全ての参加者がSerializableを実装しなければならない何らかのフレームワークに参加するためにクラスやインターフェースが主に存在している場合」は破ってもいい
- 例えば、ThrowableはSerializableを実装しているので、リモートメソッド呼び出し(RMI)からの例外を、クライアントに渡せる
- Component、HttpServletもSerializableを実装している

3. 項目 87 カスタムシリアライズ形式の使用を検討する

3.1. 結論

Javaにおけるシリアライズの実装方法は2通りある。

Effective Java 3rd [Chapter 11] - 並行性

2020-02-22

effective-java-3rd

9161 words 19 mins read

並行性

Effective Java 第 3 版の個人的メモ

項目 78 共有された可変データへのアクセスを同期する
項目 79 過剰な同期は避ける
項目 80 スレッドよりもエグゼキュータ、タスク、ストリームを選ぶ
項目 81 wait と notify よりも並行処理ユーティリティを選ぶ
項目 82 スレッド安全性を文書化する
項目 83 遅延初期化を注意して使う
項目 84 スレッドスケジューラに依存しない

1. 項目 78 共有された可変データへのアクセスを同期する

1.1. 結論

synchronizedは同期化を行い、アトミック性と可視性を保証する
複数スレッドが可変データを共有する場合には、そのデータを読み書きするスレッドは同期を行わなければならない
- 同期を行わなければ、あるスレッドで行われた変更が他のスレッドから見えることが保証されないから
volatileはアトミック性は保証しないが、可視性を保証する
スレッド間通信だけが必要で、相互排他が必要なければ、volatileを使用できるが、正しく使うのは難しい
- 相互排他が必要かどうかを判断するのが難しいから
可変データの共有はなるべく回避すべき
- 扱いが難しいから

1.2. アトミック性

1つのスレッドだけがある時点で1つのメソッドやブロックを実行する性質
下のようにsynchronizedを使うと、メソッドや処理をアトミックにできる

1
2
3


public synchronized void method() { 
  //アトミックな処理
}

1.3. 可視性

あるスレッドから変数に書き込んだ値が、別スレッドから観測できる性質
下記のクラスのバックグラウンドスレッドは停止するか？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


public class StopThread1 {
  private static boolean stopRequested;

  public static void main(String[] args) throws InterruptedException {
    Thread backgroundThead = new Thread(() -> {
      int i = 0;
      while (!stopRequested) {
        i++;
      }
    });
    backgroundThead.start();
    TimeUnit.SECONDS.sleep(1);
    stopRequested = true;
  }
}

バックグラウンドスレッドは無限ループする可能性がある
- バックグラウンドスレッドからメインスレッドのbackgroundTheadに書き込んだ値が見えるかが保証されないから
下記のクラスのバックグラウンドスレッドは停止するか？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


public class StopThread2 {
  private static boolean stopRequested;

  private static synchronized void requestStop() {
    stopRequested = true;
  }

  private static synchronized boolean stopRequested() {
    return stopRequested;
  }

  public static void main(String[] args) throws InterruptedException {
    Thread backgroundThead = new Thread(() -> {
      int i = 0;
      while (!stopRequested()) {
        i++;
      }
    });
    backgroundThead.start();
    TimeUnit.SECONDS.sleep(1);
    requestStop();
  }
}

バックグラウンドスレッドは停止することが保証される
- 読み込み操作と書き込み操作の両方が同期されていて、バックグラウンドスレッドからメインスレッドのbackgroundTheadに書き込んだ値が見えることが保証されるから

1.4. volatile

volatileはアトミック性は保証しないが、可視性を保証する
先ほどのStopThread2クラスはvolatileを使うことで、下記のようにより簡単なコードにできる
- synchronizedを相互排他のためではなく、スレッド間通信のためだけにしようしているから

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


public class StopThread3 {
  private static volatile boolean stopRequested;

  public static void main(String[] args) throws InterruptedException {
    Thread backgroundThead = new Thread(() -> {
      int i = 0;
      while (!stopRequested) {
        i++;
      }
    });
    backgroundThead.start();
    TimeUnit.SECONDS.sleep(1);
    stopRequested = true;
  }
}

volatileは「アトミックのように見えて実はアトミックではない」という操作に対して使わないようにする注意が必要
- volatileはアトミック性を保証しないから
- 例えば、下記のgenerateSerialNumber()を複数のスレッドから呼び出したら、違う値が帰ってくるか？
1 2 3 4 5

private static volatile int nextSerialNumber = 0; public static int generateSerialNumber() { return nextSerialNumber++; }
- 違う値が帰ってくることは保証されない
  - インクリメントは「アトミックに見えるが実はアトミックでない操作」だから。インクリメントは、値の読み出しと古い値に1を加えた値を書き戻す2つの操作を行う。スレッドが古い値を読み出して新たな値を書き戻す間に、別のスレッドがフィールドを読み出すと、最初のスレッドと同じ値が見えて、同じ値を返してしまう
- nextSerialNumber + 1 はまずどこに書き込まれているか？
  - スタック上の一時領域
  - メモリは参照と書き込みだけしかできない。計算できない。