Coders Conquer Security:シェア＆ラーンシリーズ - 安全でないデシリアライゼーション
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
Jaap Karan Singh
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security:シェア＆ラーンシリーズ - 安全でないデシリアライゼーション
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
