はじめに
第1回の記事ではApache Commons Collectionsライブラリのデシリアライズに関する脆弱性と脆弱性を悪用した攻撃について、第2回の記事ではデシリアライズ時に発生し得る一般的なセキュリティ問題について説明し、外部から受け取ったシリアライズデータを検証なしにデシリアライズすることはリスクを伴うことを解説した。ポイントを整理しておく。
1. 意図しないクラスのオブジェクトが生成される可能性がある
クラスパス上に存在する任意のクラスのオブジェクトを、攻撃者が指定するままに生成してしまう可能性がある。クラスパス上には、OSS、サードパーティソフトなどさまざまなライブラリが存在することが多く、それらクラスのデシリアライズ処理を悪用される可能性がある。第1回で解説したApache Commons Collectionsライブラリのクラスの悪用もその一例だ。
2. デシリアライズ処理の意図しない呼び出しやシリアライズデータの細工が行われる可能性がある
アプリケーションでデシリアライズすることを想定しているクラスであっても、readObjectメソッドなどで外部コマンド起動など攻撃に使えそうな処理が実装されている場合は、デシリアライズ処理が悪用されるリスクがある。
また、攻撃者が細工したシリアライズデータなど、意図しないオブジェクトをデシリアライズしてしまった場合、アプリケーションの挙動に影響を与える可能性がある。
上記を踏まえ、今回は外部から受け取ったデータをデシリアライズする際に発生し得るセキュリティ問題に対する対策について解説する。
セキュアなデシリアライズとは
前述した問題について、各問題に対応する対策を説明する。
1. 意図しないクラスのデシリアライズは行わない
「1．意図しないクラスのオブジェクトが生成される可能性がある」問題に対する対策。
2. 意図しないデータのデシリアライズは行わない
「2．デシリアライズ処理の意図しない呼び出しやシリアライズデータの細工が行われる可能性がある」問題に対する対策。
3. その他、デシリアライズ処理を悪用した攻撃の影響を軽減するための参考情報
第1回で解説した攻撃手法を防ぐためには、1の対策が必須だ。その他の対策については、第2回で解説した攻撃が成立する条件とアプリケーションの性質を考慮した上で、ご検討いただければと思う。
デシリアライズ処理をセキュアに実装する方法について、米国CERT Divisionがセキュアコーディングスタンダードを公開しており、JPCERT/CCがその日本語版を公開している。以下では、セキュアコーディングスタンダードをベースにポイントを絞って解説する。
では、各対策について具体的に見ていこう。
