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 ブログをご覧ください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
