【Java】Serializableの実装、役割、使い方、危険性とその対策【serialVersionUIDとは】

前書き: Javaの勉強中に見つけたSerializable

2021年になってから、腰を据えてJavaの勉強を始めました。

              

私はJava学習の一環としてJava Core APIのソースコードを読んでおり、その際にjava.io.FileクラスでSerializableインターフェースをimplementsしている記述を見かけました。

「Serializableインターフェースは、クラスをByte配列に変換するために用いる」という理解でしたが、詳細な内容については知識がありませんでした。

そのため、本記事ではSerializableインターフェースに関する調査内容を紹介します。

                  

Serializableインターフェースの実装

Serializableインターフェースは、java.baseモジュールのjava.ioパッケージに実装があります。

中身は空のため、インターフェースを実装するクラスに特定の属性を付与するためのマーカーインタフェースである事が分かります。

                 

Serializableインターフェースの役割

Serializableインターフェースを継承したクラスは、そのクラス自体をByte配列(シリアライズされたデータ)として他の仮想マシンに送信したり、ファイルとして保存できます。Byte配列をデシリアライズ(クラスに復元)する事もできます。

データを可搬性(ポータビリティ)のある形にしたい時、使用するイメージです。

Serializableインターフェースの役割(機能)
  • オブジェクト(データ)をシリアライズ/デシリアライズ可能
  • シリアライズしたデータは、Byte配列として送信可能
  • シリアライズしたデータは、ファイルとして書き出し可能    

※ 正確には、ObjectOutputStreamクラス/ObjectInputStreamクラスがSerializableインターフェースを実装したクラスをシリアライズ/デシリアライズします。

           

シリアライズ対象/対象外のデータ 

クラスには、大別してメソッド(関数)とフィールド(変数)があります。この中で、シリアライズされるデータ/シリアライズされないデータは以下の通りです。

  • シリアライズ対象 :フィールド
  • シリアライズ対象外:メソッド、static修飾子やtransient修飾子の付いたフィールド

以上を踏まえ、サンプルクラスを以下に示します(serialVersionUIDの説明は、後述します)。

             

serialVersionUIDとは

serialVersionUIDは、シリアライズしたデータのバージョン情報です。

異なるバージョンのシリアライズデータのデシリアライズを試みた場合、InvalidClassExceptionが発生します。基本的には、クラスに変更が加わったタイミングでバージョンを変更します。未定義の場合は、コンパイラがWarningを出します。

一般的には人間がserialVersionUIDを手動で追加せず、エディタやIDEの自動生成機能でlong型の数値を定義します。Eclipse、IntelliJ IDE、Visual Studio Codeは、serialVersionUIDの自動生成に対応しています。

バージョン管理が不要な場合は、@SuppressWarningsでWarningを抑制できます。

                   

シリアライズ/デシリアライズの実装例

実装例として、Serializableインターフェースを実装したSampleSerialクラスをserial.serバイナリとしてシリアライズし、serial.serバイナリをデシリアライズするコードを以下に示します。

なお、シリアライズしたバイナリの拡張子は、慣習的に”.ser”とするようです。

                   

実行例は、以下の通りです。

デシリアライズ前後で、SampleSerialインスタンスのフィールド情報が変化している事が分かります。transient修飾子を付けたフィールド(company)は、シリアライズされていないため、デシリアライズ後にnullとなっています。

なお、serial.serバイナリは、以下の状態で出力されていました。

               

Serializableインターフェースの危険性と対策

Effective Java(第三版)で触れられていますが、Serializableインターフェース(正確にはデシリアライズ処理)は、悪意を持ったプログラムの攻撃対象となる可能性が高いです。

改変されたシリアライズデータをデシリアライズしてしまうと、セキュリティ問題を引き起こす可能性があります(例:デシリアライズを悪用したリモートコード実行)。下手に実装すると、脆弱性のあるプログラムとなってしまいます。

では、どのように対策すべきかと言えば、以下の項目が一般的のようです。

シリアライズ/デシリアライズに対するセキュリティ対策
  • 意図しないデータ/クラスのデシリアライズを避ける
  • セキュリティマネージャによるチェックを必ず実施する
  • シリアライズ/デシリアライズの代替手段として、json形式を使用する

                  

JPCERT CCで様々な対策が示されていますが、どれも「難しい事を簡単そうに言ってくれますね」という印象です(個人の感想です)。

そもそも、シリアライズ/デシリアライズを利用しなければいけない場面は、あまり多くはありません。パッと思いつくのは、ネットワークに関する低レイヤーのアプリぐらいです。もしくは、難読化を施したいデータ(例:ゲームのセーブデータなど)でしょうか。

そのため、プログラム言語や環境を選ばないjson形式でデータのやり取りを実施した方が現代的と思われます。Web APIは殆どがjson形式ですし、ネット上の知見の多さを踏まえても、json形式は好ましいフォーマットではないでしょうか。

                 

後書き

調査した内容の結論が「Serializableインターフェースを使用しない方が良い」は、堪えますね。

C言語では構造体のパディングを意識しながらパケットヘッダを作成した記憶がありますが、Javaではもう少し直感的にByte配列を作れそうに感じました。

                   

おすすめ