信頼できないデータのデシリアライズ：リモートコード実行の脆弱性解説
はじめに
サイバーセキュリティの脅威が進化する中で、インセキュアなデシリアライズほど重大なリスクをもたらす脆弱性は少ないです。この重要なセキュリティ欠陥は、OWASPのTop 10脆弱性リストの中でも常に上位に位置し続けています。2025年の最近の事例には、Sitecore製品のViewStateデシリアライズのゼロデイ脆弱性（CVE-2025-53690）やMicrosoft SharePointのCVE-2025-30382などがあり、デシリアライズ攻撃は依然として継続的かつ進化し続ける脅威であることを示しています。
デシリアライズの脆弱性を悪用すると、リモートコード実行（RCE）につながる可能性があり、攻撃者は影響を受けるシステムを完全に制御できるようになります。これらの脆弱性の仕組み、リスク、予防策を理解することは、開発者やセキュリティ専門家、組織がデジタル資産を守るために不可欠です。
シリアライズとデシリアライズとは何か？
脆弱性の詳細に入る前に、シリアライズとデシリアライズの基本的な概念を理解しましょう。
シリアライズは、オブジェクトやデータ構造を保存または送信可能な形式に変換するプロセスです。これには、オブジェクトをJSON、XML、バイナリ形式、または他の構造化された表現に変換することが含まれます。シリアライズにより、アプリケーションはオブジェクトの状態をファイルやデータベースに保存したり、ネットワーク越しに送信したりできます。
デシリアライズは、その逆のプロセスで、シリアライズされたデータからオブジェクトを再構築します。デシリアライズ中、アプリケーションはシリアライズされたデータを読み取り、元のオブジェクト構造をメモリ上に再現します。これには、そのプロパティやメソッド、状態も含まれます。
これらのプロセスは現代のアプリケーション開発において基本的なものですが、信頼できないデータが関与すると危険性が高まります。
セキュアでないデシリアライズの構造
デシリアライズは、信頼できないソースからのデータを扱う場合、リモートコード実行（RCE）などの攻撃に対して脆弱になる可能性があります。脆弱性は、アプリケーションが適切な検証やセキュリティ制御を行わずに信頼できないソースからのデータをデシリアライズする場合に発生します。
なぜデシリアライズは本質的にリスクが高いのか
根本的なリスクは、デシリアライズの過程そのものにあります。アプリケーションがデータをデシリアライズするとき、単にパッシブなデータ構造を再現しているわけではなく、コードを実行する可能性もあります。多くのシリアライズフォーマットやライブラリは、実行可能なコードやコンストラクタ、メソッド呼び出しを含む複雑なオブジェクトグラフをサポートしており、デシリアライズ中にこれらが実行されることがあります。
インセキュアなデシリアライズは、攻撃者がシリアライズされたオブジェクトを操作して有害なデータをアプリケーションのコードに渡すことを可能にし、完全に異なるタイプのオブジェクトに置き換えることもあります。
攻撃の経路と影響
インセキュアなデシリアライズの脆弱性は、攻撃者がシリアライズされたオブジェクトを制御できる場合、サーバー上で任意のコードを実行できるため、リモートコード実行（RCE）につながる可能性があります。影響はRCEを超え、次のようなものも含まれます：
- システムの完全乗っ取り：攻撃者が脆弱なシステムを完全に制御
- データの窃取：機密情報のアクセスと盗難
- 横展開：侵害されたシステムを足掛かりにさらなる攻撃
- サービス拒否（DoS）：リソース集約型のデシリアライズ操作によるシステムの過負荷
- 認証バイパス：操作されたセッションオブジェクトによるセキュリティ制御の回避
実例と最近の事例
2025年の脅威の状況は、デシリアライズの脆弱性の深刻さを示し続けています：
Sitecore ViewStateの脆弱性 (CVE-2025-53690)
この脆弱性により、インターネットに公開されているSitecoreインスタンスでリモートコード実行が可能となり、攻撃者は内部調査のためにWEEPSTEELマルウェアを展開しました。
Microsoft SharePointのデシリアライズ脆弱性 (CVE-2025-30382)
CVSSスコア7.8のこの脆弱性は、攻撃者に任意のコード実行を許し、システムの完全乗っ取りやネットワーク内の横展開を可能にします。
これらの最近の事例は、デシリアライズの脆弱性が依然として積極的に悪用されており、世界中の組織に継続的なリスクをもたらしていることを示しています。
技術的詳細：Javaのデシリアライズ攻撃
実際にデシリアライズ攻撃がどのように機能するかを示すために、Javaを例にとって一般的なシナリオを見てみましょう。Javaはこれらの攻撃で最も頻繁にターゲットとなる言語の一つです。
脆弱なJavaコード例
// 脆弱なデシリアライズコード
public class VulnerableServer {
public void handleRequest(Socket socket) throws Exception {
ObjectInputStream ois = new ObjectInputStream(socket.getInputStream());
Object obj = ois.readObject(); // 危険：信頼できない入力を受け入れる
// デシリアライズされたオブジェクトを処理
if (obj instanceof UserData) {
UserData userData = (UserData) obj;
processUserData(userData);
}
}
}
悪意のあるオブジェクトグラフがCommons Collectionsのガジェットチェーンを使って送信されると、readObject()がリモートコード実行につながる可能性があります。
攻撃の流れ
ガジェットチェーンの構築：攻撃者は、「ガジェットチェーン」と呼ばれる既存クラスのシーケンスを特定し、コード実行を達成します。
ペイロードの作成：これらのガジェットチェーンを悪用した悪意のあるシリアライズ済みオブジェクトを構築します。例としてApache Commons Collectionsを使用:
// ガジェットチェーンのペイロードの簡略化例
Transformer[] transformers = new Transformer[] {
new ConstantTransformer(Runtime.class),
new InvokerTransformer("getMethod",
new Class[] {String.class, Class[].class},
new Object[] {"getRuntime", new Class[0]}),
new InvokerTransformer("invoke",
new Class[] {Object.class, Object[].class},
new Object[] {null, new Object[0]}),
new InvokerTransformer("exec",
new Class[] {String.class},
new Object[] {"calc.exe"}) // 計算機を起動
};
Transformer transformerChain = new ChainedTransformer(transformers);
Map map = new HashMap();
map.put("value", "value");
Map transformedMap = TransformedMap.decorate(map, null, transformerChain);
ペイロードの送信：悪意のあるシリアライズ済みオブジェクトは、HTTPリクエストやネットワークソケット、メッセージキューなどを通じて脆弱なアプリケーションに送信されます。
コードの実行：アプリケーションがペイロードをデシリアライズすると、ガジェットチェーンが実行され、攻撃者のコードがアプリケーションの権限で動作します。
PythonのPickleの脆弱性
Pythonのpickleモジュールも同様のリスクを持ちます。次の脆弱なコード例を見てみましょう：
import pickle
import socket
def handle_request(conn):
data = conn.recv(4096)
obj = pickle.loads(data) # 危険：信頼できないデータをデシリアライズ
return obj
攻撃者は悪意のあるpickleペイロードを作成できます：
import pickle
import subprocess
class MaliciousPayload:
def __reduce__(self):
return (subprocess.call, (['calc.exe'],))
# 悪意のあるペイロードをシリアライズ
payload = pickle.dumps(MaliciousPayload())
# 脆弱なサーバに送信...
脆弱なアプリケーションがこのペイロードをデシリアライズすると、subprocess.call関数が実行され、計算機アプリケーション（または攻撃者が指定した他のコマンド）が起動します。
高度な攻撃技術
Property-Oriented Programming (POP)
攻撃者はProperty-Oriented Programmingを利用して、既存のコードパスを活用したガジェットチェーンを構築します。オブジェクトのプロパティを巧みに操作することで、デシリアライズ中にメソッド呼び出しをトリガーし、コード実行を引き起こすことが可能です。
ブラインドデシリアライズ攻撃
アプリケーションが直接デシリアライズされたオブジェクトを使用しなくても、コンストラクタ呼び出しや静的イニシャライザなど、デシリアライズ中の副作用を通じてコード実行を達成できる場合があります。
多態性ペイロード
高度な攻撃者は、異なる環境やクラスパスに適応できるペイロードを作成し、多様なターゲットシステムでの成功率を高めます。
検出と識別
デシリアライズの脆弱性を特定するには、コード分析と実行時テストの両方が必要です：
静的コード分析
- デシリアライズメソッドで信頼できない入力を受け入れているか
- 危険なライブラリ（ObjectInputStream、pickleなど）の使用を特定
- 入力検証とサニタイズの手順をレビュー
動的テスト
- ネットワークトラフィックにシリアライズされたデータパターンを監視
- 悪意のあるペイロードでアプリケーションをテスト
- デシリアライズの脆弱性向けのセキュリティテストツールを使用
実行時監視
- デシリアライズ操作のログを記録
- 不審なオブジェクトのインスタンス化を監視
- デシリアライズ中の異常なシステムコールを追跡
総合的な予防策
予防策には、データストリームにデシリアライズされるオブジェクトの型を定義させないことや、可能な限りDataContractSerializerやXmlSerializerなどの安全な代替手段を使用することが含まれます。
1. 信頼できないデータのデシリアライズを避ける
最も効果的な防御策はシンプルです：信頼できないソースからのデータを絶対にデシリアライズしないことです。この基本原則が攻撃ベクトルを完全に排除します。
// 安全なアプローチ：構造化データフォーマットを使用
public class SecureHandler {
public void handleRequest(HttpServletRequest request) {
// Javaシリアライズの代わりにJSONを使用
String jsonData = request.getParameter("data");
ObjectMapper mapper = new ObjectMapper();
UserData userData = mapper.readValue(jsonData, UserData.class);
}
}
2. 厳格な入力検証の実施
デシリアライズが避けられない場合は、包括的な検証を実装します：
public class ValidatingObjectInputStream extends ObjectInputStream {
private SetString allowedClasses;
public ValidatingObjectInputStream(InputStream in, SetString allowedClasses) {
super(in);
this.allowedClasses = allowedClasses;
}
@Override
protected Class? resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
String className = desc.getName();
if (!allowedClasses.contains(className)) {
throw new InvalidObjectException("未承認のデシリアライズ試行: " + className);
}
return super.resolveClass(desc);
}
}
3. ホワイトリスト方式の採用
許可されたクラスやオブジェクトだけをデシリアライズするよう制限し、ホワイトリストを維持します。
4. サンドボックス化
デシリアライズ操作を制限された環境で実行し、権限を制御します：
// 例：デシリアライズ時の権限制限
AccessController.doPrivileged(new PrivilegedActionObject() {
public Object run() {
// 制限された権限でデシリアライズを実行
return deserializeWithLimitedPrivileges(data);
}
}, restrictedAccessControlContext);
5. より安全な代替手段の利用
ネイティブのシリアライズを、安全なフォーマットに置き換えます：
- JSON：人間に読みやすく、パース時にコードを実行しません
- Protocol Buffers：厳格なスキーマ検証を行うバイナリフォーマット
- MessagePack：コード実行リスクのない効率的なバイナリフォーマット
- XML with schema validation：検証機能付きの構造化フォーマット
6. 実行時保護の実装
# Pythonの例：pickle操作の制限
import pickle
import builtins
class RestrictedUnpickler(pickle.Unpickler):
def find_class(self, module, name):
# 安全なビルトインのみ許可
if module == "builtins" and name in ["list", "dict", "str", "int"]:
return getattr(builtins, name)
raise pickle.UnpicklingError(f"禁止されたクラス: {module}.{name}")
def safe_loads(data):
return RestrictedUnpickler(io.BytesIO(data)).load()
業界のベストプラクティスと標準
OWASPガイドライン
OWASPの包括的なガイダンスに従い、不安全なデシリアライズを防止します。これには、アーキテクチャの推奨事項、安全なコーディングプラクティス、テスト手法が含まれます。
セキュリティを設計に組み込む
セキュリティをソフトウェア開発ライフサイクルの最初から考慮し、後付けにしないことが重要です。
定期的なセキュリティ評価
潜在的なデシリアライズの脆弱性を早期に発見するために、定期的なセキュリティレビューやペネトレーションテストを実施します。
監視とインシデント対応
ロギングとアラート
デシリアライズ操作の包括的なログ記録を実施します：
logger.info("クラス: {} からのデシリアライズ試行。ソース: {}", className, requestSource);
インシデント対応手順
デシリアライズ攻撃に対する具体的な対応手順を策定します。例： - 直ちに隔離する戦略 - フォレンジック分析手順 - 復旧と修復のステップ - コミュニケーションのプロトコル
今後の展望と新たな脅威
2025年の最新の脆弱性からもわかるように、デシリアライズ攻撃は進化し続けています。組織は次の点に注意し、セキュリティ戦略を適応させる必要があります：
- 新しい攻撃経路や手法
- 新たなシリアライズフォーマットやライブラリ
- クラウドネイティブやマイクロサービスアーキテクチャ
- シリアライズされたデータを処理するAIや機械学習アプリケーション
結論
信頼できないデータのデシリアライズは、現代アプリケーションセキュリティにおいて最も重要な脆弱性の一つです。悪意のあるシリアライズデータを注入されると、攻撃者はサーバー上で任意のコードを実行し、システムを完全に制御できます。2025年の高-profileな事例は、この脅威が依然として存在し、進化し続けていることを強く示しています。
これらの攻撃から身を守るための基本原則はシンプルです：コントロールできないデータは絶対にデシリアライズしないことです。必要な場合は、厳格な入力検証、ホワイトリスト、サンドボックス化、監視の複数層の防御策を実施してください。
組織は、セキュアなコーディング実践、リスクを最小化するアーキテクチャの決定、継続的なセキュリティ評価を通じて、デシリアライズの脆弱性に対処することを優先すべきです。これらの攻撃の仕組みを理解し、堅牢な予防策を実施することで、開発者やセキュリティチームはこの重要な脆弱性クラスへの露出を大幅に減らすことができます。
予防のコストは、侵害のコストよりも常に低いです。1つの成功したデシリアライズ攻撃がシステム全体の乗っ取りやビジネスへの大きな影響につながる時代において、適切なセキュリティ対策への投資は推奨されるだけでなく、組織の存続にとって不可欠です。
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.