コーダーがセキュリティを制する:共有&学習シリーズ - 安全でないデシリアライゼーション

アプリケーションによっては、シリアライズのプロセスが常に行われています。これは、データ構造やオブジェクトの状態を、保存や通信送信が可能な形式に変換することを指す用語です。デシリアライズはその逆のプロセスであり、構造化されたデータを元のオブジェクトやデータ文字列に戻す作業です。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に発生します。ユーザーが再構築されたデータを改ざんできる場合、コードインジェクションやサービス拒否攻撃といった悪意ある活動だけでなく、単にデータを変更してアプリケーション内で有利な状況を作り出す(商品の価格を下げる、権限を昇格させるなど)といった行為が可能になります。
本エピソードでは、以下の内容を学びます。
- 攻撃者が安全でないデシリアライズを悪用する方法
- 安全でないデシリアライズが危険な理由
- この脆弱性を修正する技術
攻撃者はどのようにして安全でないデシリアライズを悪用するのか?
現在、データシリアライズで最も一般的な形式はJSONですが、XMLもそれに次ぐ普及率を誇ります。多くのプログラミング言語には独自のシリアライズ手法があり、JSONやXMLよりも多くの機能を備えていることがよくあります。いずれにせよ、開発者がデシリアライズされたデータを信頼できる入力として扱うようにプログラムを組むと問題が発生します。本シリーズの他のブログで繰り返し述べている「ユーザー入力を決して信頼するな!」という鉄則に従う必要があります。
ユーザー入力は決して信頼してはいけません。ユーザーが文字列にコードを挿入し、それが受信側のサーバーで意図せず実行される可能性があるからです。また、デシリアライズされた生のデータもアクセスや悪用の対象となることがあるため、同様に「信頼できないもの」として扱う必要があります。
例えば、フォーラムアプリケーションがPHPオブジェクトのシリアライズを使用して、ユーザーの識別情報と役割を含むクッキーを保存している場合、そのクッキーは操作される可能性があります。悪意のあるユーザーが自分の「ユーザー」権限を「管理者」に変更するかもしれません。あるいは、データ文字列の隙を突いてコードを注入し、サーバーがその「信頼できる」データを処理する際に誤って実行させてしまう可能性もあります。
なぜ安全でないデシリアライズは危険なのか?
確かに、この種の攻撃にはハッカー側に一定のスキルが求められます。また、サーバーが操作されたデシリアライズデータを受け入れるかどうかを確認するために、試行錯誤が必要になることもあります。しかし、この脆弱性は、使いこなせるハッカーに多大な権限を与える可能性があるため、非常によく悪用されています。
デシリアライズされたデータがどのように使用されるかによって、過去のブログで取り上げたものを含む、あらゆる種類の攻撃が実行可能です。安全でないデシリアライズは、リモートコードインジェクション、クロスサイトスクリプティング(XSS)、サービス拒否攻撃、アクセス制御の乗っ取り、そしてSQLやXMLインジェクション攻撃への入り口となり得ます。基本的には攻撃の足がかりとなり、デシリアライズされるすべてのデータを「信頼できる」と宣言させて、攻撃者に悪用の機会を与えてしまうのです。
安全でないデシリアライズの排除
組織が安全でないデシリアライズを防ぐためにできる最も安全な対策は、アプリケーションがデシリアライズされたデータを受け入れないように制限することです。しかし、それが現実的ではない場合もあります。ご安心ください。この種の攻撃を防ぐために採用できる他の技術があります。
可能であれば、データを数値などの形式にサニタイズ(無害化)します。これだけでは攻撃を完全に阻止できないかもしれませんが、コードインジェクションの発生は防げます。さらに良いのは、デジタル署名などの整合性チェックをデシリアライズデータに対して必須にすることです。これにより、データ文字列が改ざんされていないことを保証できます。また、すべてのデシリアライズ処理は分離し、権限の低い環境で実行すべきです。
これらの保護策を導入したら、デシリアライズに失敗したすべての試行と、データをデシリアライズするコンテナやサーバーからのネットワークアクティビティを必ずログに記録してください。ログ内で特定のユーザーが何度もデシリアライズエラーを引き起こしている場合、そのユーザーが悪意のある内部関係者であるか、資格情報が盗まれている可能性が高いと言えます。デシリアライズエラーを繰り返すユーザーを自動的にロックアウトすることも検討すべきでしょう。
どのようなツールを使って安全でないデシリアライズに対抗するにしても、根本にあるのは「ユーザーによって触れられたり操作されたりした可能性のあるデータである」という事実です。決して信頼してはいけません。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
詳細については、OWASPによる安全でないデシリアライゼーションに関する解説をご覧ください。また、習得した防御知識を試すには、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warriorプラットフォームの無料ショーケースをご活用ください。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warriorブログをご覧ください。
AI主導の開発をリリース前にガバナンスする
AIを活用したリスク測定、コミット時のセキュアコーディングポリシーの強制、そしてSDLC全体を通じたセキュアなデリバリーの加速を実現します。
他のブログ記事を見る
セキュアコーディング、AIガバナンス、ソフトウェアリスク管理に関する専門的なコンテンツをご覧ください。
%252520%252520(3).avif)
Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Security as culture: How Blue Prism cultivates world-class secure developers
Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed
AIを活用した開発をリリース前にセキュアに
開発者のリスクを可視化し、ポリシーを適用することで、ソフトウェア開発ライフサイクル全体における脆弱性を未然に防ぎます。



.avif)