Coders Conquer Security:シェア＆ラーンシリーズ - 安全でないデシリアライゼーション
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードの注入、サービス拒否攻撃、特権の昇格など、あらゆる種類の悪意ある活動を行うことができます。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
アプリケーションにもよりますが、シリアル化のプロセスは常に行われています。シリアル化とは、データ構造やオブジェクトの状態を、保存や通信が可能な形式に変換することを指しています。デシリアライゼーションは、このプロセスの逆で、構造化されたデータを、保存前のオブジェクトやデータ文字列に戻すことです。
安全でないデシリアライズは、アプリケーションがデシリアライズされるデータを信頼できるものとして扱う場合に起こります。ユーザーが新たに再構成されたデータを変更することができれば、コードインジェクション、サービス拒否攻撃、あるいは単にデータを変更して、オブジェクトの価格を下げたり、権限を昇格させたりするなど、アプリケーション内で自分が有利になるような、あらゆる種類の悪意ある活動を行うことができます。
このエピソードでは、以下のことを学びます。
- 安全でないデシリアライゼーションを攻撃者がどのように利用するか
- なぜ安全でないデシリアライゼーションが危険なのか
- この脆弱性を修正することができる技術
攻撃者はどのようにして安全ではないデシリアライゼーションを利用するのか？
最近では、データをシリアライズするための最も一般的なデータ形式はJSONですが、XMLもそれに次ぐものです。また、多くのプログラミング言語が、データをシリアル化する独自の方法を提供しており、JSONやXMLよりも多くの機能を備えています。いずれにしても、開発者がシリアライズされたデータを信頼できる入力として扱うようにアプリをプログラムすると、問題が発生する可能性があります。"具体的には、「ユーザーの入力を信用してはいけない！」ということです。
ユーザーが文字列にコードを挿入すると、受信側のサーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた生のデータも、時にはアクセスされて悪用される可能性があるため、同じように信頼されないカテゴリーに入る必要があります。
例えば、フォーラムのアプリケーションがPHPのオブジェクト・シリアライゼーションを使用して、ユーザの識別情報と役割を含むクッキーを保存している場合、そのクッキーを操作することができます。悪意のあるユーザーは、自分の「ユーザー」ロールを「admin」に変更するかもしれません。あるいは、データ文字列によって提供される開口部を利用してコードを注入し、「信頼された」データを処理する際にサーバーが誤って解釈して実行する可能性があります。
なぜ安全でないデシリアライゼーションは危険なのか？
確かに、この種の攻撃には、ハッカーのある程度のスキルが必要であり、攻撃者が、操作されたデシリアライズされたデータから、サーバーがどのようなコードや悪用を受け入れるかを学ぶ間、試行錯誤することもあります。とはいえ、この脆弱性は、十分な技術を持ったハッカーに潜在的な力を与えるため、よく悪用される脆弱性です。
デシリアライズされたデータがどのように使用されるかによって、以前のブログで紹介したものも含め、様々な攻撃を受ける可能性があります。安全でないデシリアライズは、リモートでのクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセスコントロールのハイジャック、そしてもちろんSQLやXMLインジェクション攻撃へのゲートウェイとなり得ます。基本的には、デシリアライズされるすべてのデータが信頼できるものであると宣言して、攻撃者にそれを利用させることができます。
安全でないデシリアライゼーションの排除
安全でないデシリアライズを防ぐために組織ができる最も安全なことは、アプリケーションがデシリアライズされたデータを受け取らないように制限することです。しかし、それは不可能であり、現実的ではないかもしれません。しかし、この種の攻撃を防御するために他の技術を採用することができるので、心配する必要はありません。
可能であれば、データを数値のようにサニタイズすることができます。これにより、エクスプロイトを完全に防ぐことはできないかもしれませんが、コードインジェクションの発生を防ぐことができます。さらに良いのは、デジタル署名など、デシリアライズされたデータに対する何らかの整合性チェックを要求することで、データの文字列が操作されていないことを確実にすることができます。また、すべてのデシリアライズ処理は隔離され、低い権限の環境で実行されるべきです。
これらの保護措置を講じた後は、データの再シリアライズを行うコンテナやサーバからのネットワーク・アクティビティだけでなく、再シリアライズの失敗もすべてログに記録するようにしてください。ログに2回以上のシリアル化エラーが発生したユーザーは、悪意のあるインサイダーであるか、認証情報がハッキングされたり盗まれたりした可能性が高いと考えられます。常にシリアル化エラーを引き起こすユーザーを自動的にロックアウトするなどの対策も考えられます。
安全でないデシリアライゼーションに対抗するためにどのようなツールを使ったとしても、基本的には、ユーザーが触れたり操作したりした可能性のあるデータであることを忘れないでください。決して信用してはいけません。
脆弱性が指摘されているコンポーネントの使用に関する詳細情報
さらに詳しい情報は、OWASPが安全でないデシリアライゼーションについてどのように述べているかをご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士へと育成するSecure Code Warrior プラットフォームの無料ショーケースで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
