コーダーがセキュリティを征服:Share & Learn シリーズ-安全でないデシリアライゼーション
アプリケーションによっては、シリアル化のプロセスが常に行われることがあります。これは、データ構造やオブジェクトの状態が、保存や通信として送信できる形式に変換されるたびに使われる用語です。逆シリアル化はこのプロセスの逆で、構造化されたデータを格納前のオブジェクトまたはデータ文字列に戻します。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、あるいは単にデータを変更してオブジェクトの価格を下げたり、権限を昇格させたりするなど、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
このエピソードでは次のことを学びます。
- 攻撃者が安全でない逆シリアル化を悪用する方法
- 安全でない逆シリアル化が危険な理由
- この脆弱性を修正できるテクニック。
攻撃者は安全でない逆シリアル化をどのように悪用するか?
最近では、データをシリアル化するための最も一般的なデータ形式は JSON ですが、XML がそれに次ぐ形式です。かなりの数のプログラミング言語が独自の方法でデータをシリアル化していますが、その方法には JSON や XML よりも多くの機能が含まれていることがよくあります。いずれにしても、この連載の他のブログの古いモットーである「ユーザーの入力を絶対に信用してはいけない！」に従うのではなく、デシリアライズされたデータを信頼できる入力として扱うように開発者がアプリをプログラミングすると、問題が発生する可能性があります。
ユーザーがこれらの文字列にコードを挿入すると、受信サーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた未加工のデータにもアクセスされて悪用されることがあるため、これも信頼できないカテゴリに分類する必要があります。
たとえば、フォーラムアプリケーションが PHP オブジェクトのシリアル化を使用してユーザーの識別情報とロールを含む Cookie を保存する場合、それを操作できます。悪意のあるユーザーが、「ユーザー」の役割を「admin」に変更する可能性があります。あるいは、データ文字列の開口部を利用してコードを挿入することもできますが、サーバーが「信頼できる」データを処理する際に、そのコードを誤って解釈して実行してしまう可能性があります。
安全でない逆シリアル化はなぜ危険なのですか?
確かに、この種の攻撃にはハッカー側にある程度のスキルが必要であり、攻撃者が操作および逆シリアル化されたデータからサーバーがどのようなコードやエクスプロイトを受け入れるかを攻撃者が学習する間、試行錯誤が必要になることもあります。とはいえ、この脆弱性は悪用されがちです。というのも、この脆弱性を悪用できるほど熟練したハッカーに潜在的に威力を与える可能性があるからです。
逆シリアル化されたデータの使用方法によっては、以前のブログで取り上げた攻撃を含め、いくつでも攻撃を仕掛けることができます。安全でない逆シリアル化は、リモートクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセス制御ハイジャック、そしてもちろん SQL や XML インジェクション攻撃への入り口となる可能性があります。これは基本的に、デシリアライズされるすべてのデータを信頼できるものとして宣言し、攻撃者が悪用を試みるきっかけとなります。
安全でない逆シリアル化の排除
安全でない逆シリアル化を防ぐために組織ができる最も安全なことは、アプリケーションが逆シリアル化されたデータを受け入れることを制限することです。ただし、このような攻撃を防ぐ方法は他にもあるため、これは不可能であるか、現実的ではないかもしれませんが、心配はいりません。
可能であれば、データを数値のようなものにサニタイズできます。これによって悪用が完全に阻止されるわけではありませんが、コードインジェクションは防げます。さらに良いのは、デジタル署名などの逆シリアル化されたデータに対して何らかの形式の整合性チェックを行うだけで、データ文字列が操作されていないことを確認できることです。また、デシリアライズ処理はすべて分離し、権限の低い環境で実行する必要があります。
これらの保護策を講じたら、失敗したすべての逆シリアル化試行と、データを逆シリアル化するコンテナまたはサーバーからのネットワークアクティビティを必ずログに記録してください。ユーザーがログでシリアル化解除エラーを 2 回以上発生させた場合は、そのユーザーが悪意のある内部関係者であるか、認証情報がハッキングされたり盗まれたりした可能性があると考えられます。逆シリアル化エラーを頻繁に引き起こすユーザーの自動ロックアウトのようなことを検討するかもしれません。
安全でない逆シリアル化に対処するためにこれらのツールのどれを使用するにしても、核となるのはユーザーによって触れたり操作されたりする可能性のあるデータであることを忘れないでください。決して信用しないでください。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
さらに読み進めるには、OWASPが何を言っているか見てみましょう 安全でない逆シリアル化について。また、新しく身につけた防御知識を、次の方法で試すこともできます 無料ショーケース サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、権限の昇格など、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior는 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 구축하는 데 도움을 드립니다. 애플리케이션 보안 관리자, 개발자, CISO 또는 보안 담당자이든, 안전하지 않은 코드와 관련된 위험을 줄이는 데 도움을 드립니다.
데모 예약
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
アプリケーションによっては、シリアル化のプロセスが常に行われることがあります。これは、データ構造やオブジェクトの状態が、保存や通信として送信できる形式に変換されるたびに使われる用語です。逆シリアル化はこのプロセスの逆で、構造化されたデータを格納前のオブジェクトまたはデータ文字列に戻します。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、あるいは単にデータを変更してオブジェクトの価格を下げたり、権限を昇格させたりするなど、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
このエピソードでは次のことを学びます。
- 攻撃者が安全でない逆シリアル化を悪用する方法
- 安全でない逆シリアル化が危険な理由
- この脆弱性を修正できるテクニック。
攻撃者は安全でない逆シリアル化をどのように悪用するか?
最近では、データをシリアル化するための最も一般的なデータ形式は JSON ですが、XML がそれに次ぐ形式です。かなりの数のプログラミング言語が独自の方法でデータをシリアル化していますが、その方法には JSON や XML よりも多くの機能が含まれていることがよくあります。いずれにしても、この連載の他のブログの古いモットーである「ユーザーの入力を絶対に信用してはいけない！」に従うのではなく、デシリアライズされたデータを信頼できる入力として扱うように開発者がアプリをプログラミングすると、問題が発生する可能性があります。
ユーザーがこれらの文字列にコードを挿入すると、受信サーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた未加工のデータにもアクセスされて悪用されることがあるため、これも信頼できないカテゴリに分類する必要があります。
たとえば、フォーラムアプリケーションが PHP オブジェクトのシリアル化を使用してユーザーの識別情報とロールを含む Cookie を保存する場合、それを操作できます。悪意のあるユーザーが、「ユーザー」の役割を「admin」に変更する可能性があります。あるいは、データ文字列の開口部を利用してコードを挿入することもできますが、サーバーが「信頼できる」データを処理する際に、そのコードを誤って解釈して実行してしまう可能性があります。
安全でない逆シリアル化はなぜ危険なのですか?
確かに、この種の攻撃にはハッカー側にある程度のスキルが必要であり、攻撃者が操作および逆シリアル化されたデータからサーバーがどのようなコードやエクスプロイトを受け入れるかを攻撃者が学習する間、試行錯誤が必要になることもあります。とはいえ、この脆弱性は悪用されがちです。というのも、この脆弱性を悪用できるほど熟練したハッカーに潜在的に威力を与える可能性があるからです。
逆シリアル化されたデータの使用方法によっては、以前のブログで取り上げた攻撃を含め、いくつでも攻撃を仕掛けることができます。安全でない逆シリアル化は、リモートクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセス制御ハイジャック、そしてもちろん SQL や XML インジェクション攻撃への入り口となる可能性があります。これは基本的に、デシリアライズされるすべてのデータを信頼できるものとして宣言し、攻撃者が悪用を試みるきっかけとなります。
安全でない逆シリアル化の排除
安全でない逆シリアル化を防ぐために組織ができる最も安全なことは、アプリケーションが逆シリアル化されたデータを受け入れることを制限することです。ただし、このような攻撃を防ぐ方法は他にもあるため、これは不可能であるか、現実的ではないかもしれませんが、心配はいりません。
可能であれば、データを数値のようなものにサニタイズできます。これによって悪用が完全に阻止されるわけではありませんが、コードインジェクションは防げます。さらに良いのは、デジタル署名などの逆シリアル化されたデータに対して何らかの形式の整合性チェックを行うだけで、データ文字列が操作されていないことを確認できることです。また、デシリアライズ処理はすべて分離し、権限の低い環境で実行する必要があります。
これらの保護策を講じたら、失敗したすべての逆シリアル化試行と、データを逆シリアル化するコンテナまたはサーバーからのネットワークアクティビティを必ずログに記録してください。ユーザーがログでシリアル化解除エラーを 2 回以上発生させた場合は、そのユーザーが悪意のある内部関係者であるか、認証情報がハッキングされたり盗まれたりした可能性があると考えられます。逆シリアル化エラーを頻繁に引き起こすユーザーの自動ロックアウトのようなことを検討するかもしれません。
安全でない逆シリアル化に対処するためにこれらのツールのどれを使用するにしても、核となるのはユーザーによって触れたり操作されたりする可能性のあるデータであることを忘れないでください。決して信用しないでください。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
さらに読み進めるには、OWASPが何を言っているか見てみましょう 安全でない逆シリアル化について。また、新しく身につけた防御知識を、次の方法で試すこともできます 無料ショーケース サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
アプリケーションによっては、シリアル化のプロセスが常に行われることがあります。これは、データ構造やオブジェクトの状態が、保存や通信として送信できる形式に変換されるたびに使われる用語です。逆シリアル化はこのプロセスの逆で、構造化されたデータを格納前のオブジェクトまたはデータ文字列に戻します。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、あるいは単にデータを変更してオブジェクトの価格を下げたり、権限を昇格させたりするなど、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
このエピソードでは次のことを学びます。
- 攻撃者が安全でない逆シリアル化を悪用する方法
- 安全でない逆シリアル化が危険な理由
- この脆弱性を修正できるテクニック。
攻撃者は安全でない逆シリアル化をどのように悪用するか?
最近では、データをシリアル化するための最も一般的なデータ形式は JSON ですが、XML がそれに次ぐ形式です。かなりの数のプログラミング言語が独自の方法でデータをシリアル化していますが、その方法には JSON や XML よりも多くの機能が含まれていることがよくあります。いずれにしても、この連載の他のブログの古いモットーである「ユーザーの入力を絶対に信用してはいけない！」に従うのではなく、デシリアライズされたデータを信頼できる入力として扱うように開発者がアプリをプログラミングすると、問題が発生する可能性があります。
ユーザーがこれらの文字列にコードを挿入すると、受信サーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた未加工のデータにもアクセスされて悪用されることがあるため、これも信頼できないカテゴリに分類する必要があります。
たとえば、フォーラムアプリケーションが PHP オブジェクトのシリアル化を使用してユーザーの識別情報とロールを含む Cookie を保存する場合、それを操作できます。悪意のあるユーザーが、「ユーザー」の役割を「admin」に変更する可能性があります。あるいは、データ文字列の開口部を利用してコードを挿入することもできますが、サーバーが「信頼できる」データを処理する際に、そのコードを誤って解釈して実行してしまう可能性があります。
安全でない逆シリアル化はなぜ危険なのですか?
確かに、この種の攻撃にはハッカー側にある程度のスキルが必要であり、攻撃者が操作および逆シリアル化されたデータからサーバーがどのようなコードやエクスプロイトを受け入れるかを攻撃者が学習する間、試行錯誤が必要になることもあります。とはいえ、この脆弱性は悪用されがちです。というのも、この脆弱性を悪用できるほど熟練したハッカーに潜在的に威力を与える可能性があるからです。
逆シリアル化されたデータの使用方法によっては、以前のブログで取り上げた攻撃を含め、いくつでも攻撃を仕掛けることができます。安全でない逆シリアル化は、リモートクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセス制御ハイジャック、そしてもちろん SQL や XML インジェクション攻撃への入り口となる可能性があります。これは基本的に、デシリアライズされるすべてのデータを信頼できるものとして宣言し、攻撃者が悪用を試みるきっかけとなります。
安全でない逆シリアル化の排除
安全でない逆シリアル化を防ぐために組織ができる最も安全なことは、アプリケーションが逆シリアル化されたデータを受け入れることを制限することです。ただし、このような攻撃を防ぐ方法は他にもあるため、これは不可能であるか、現実的ではないかもしれませんが、心配はいりません。
可能であれば、データを数値のようなものにサニタイズできます。これによって悪用が完全に阻止されるわけではありませんが、コードインジェクションは防げます。さらに良いのは、デジタル署名などの逆シリアル化されたデータに対して何らかの形式の整合性チェックを行うだけで、データ文字列が操作されていないことを確認できることです。また、デシリアライズ処理はすべて分離し、権限の低い環境で実行する必要があります。
これらの保護策を講じたら、失敗したすべての逆シリアル化試行と、データを逆シリアル化するコンテナまたはサーバーからのネットワークアクティビティを必ずログに記録してください。ユーザーがログでシリアル化解除エラーを 2 回以上発生させた場合は、そのユーザーが悪意のある内部関係者であるか、認証情報がハッキングされたり盗まれたりした可能性があると考えられます。逆シリアル化エラーを頻繁に引き起こすユーザーの自動ロックアウトのようなことを検討するかもしれません。
安全でない逆シリアル化に対処するためにこれらのツールのどれを使用するにしても、核となるのはユーザーによって触れたり操作されたりする可能性のあるデータであることを忘れないでください。決して信用しないでください。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
さらに読み進めるには、OWASPが何を言っているか見てみましょう 安全でない逆シリアル化について。また、新しく身につけた防御知識を、次の方法で試すこともできます 無料ショーケース サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
アプリケーションによっては、シリアル化のプロセスが常に行われることがあります。これは、データ構造やオブジェクトの状態が、保存や通信として送信できる形式に変換されるたびに使われる用語です。逆シリアル化はこのプロセスの逆で、構造化されたデータを格納前のオブジェクトまたはデータ文字列に戻します。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、あるいは単にデータを変更してオブジェクトの価格を下げたり、権限を昇格させたりするなど、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
このエピソードでは次のことを学びます。
- 攻撃者が安全でない逆シリアル化を悪用する方法
- 安全でない逆シリアル化が危険な理由
- この脆弱性を修正できるテクニック。
攻撃者は安全でない逆シリアル化をどのように悪用するか?
最近では、データをシリアル化するための最も一般的なデータ形式は JSON ですが、XML がそれに次ぐ形式です。かなりの数のプログラミング言語が独自の方法でデータをシリアル化していますが、その方法には JSON や XML よりも多くの機能が含まれていることがよくあります。いずれにしても、この連載の他のブログの古いモットーである「ユーザーの入力を絶対に信用してはいけない！」に従うのではなく、デシリアライズされたデータを信頼できる入力として扱うように開発者がアプリをプログラミングすると、問題が発生する可能性があります。
ユーザーがこれらの文字列にコードを挿入すると、受信サーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた未加工のデータにもアクセスされて悪用されることがあるため、これも信頼できないカテゴリに分類する必要があります。
たとえば、フォーラムアプリケーションが PHP オブジェクトのシリアル化を使用してユーザーの識別情報とロールを含む Cookie を保存する場合、それを操作できます。悪意のあるユーザーが、「ユーザー」の役割を「admin」に変更する可能性があります。あるいは、データ文字列の開口部を利用してコードを挿入することもできますが、サーバーが「信頼できる」データを処理する際に、そのコードを誤って解釈して実行してしまう可能性があります。
安全でない逆シリアル化はなぜ危険なのですか?
確かに、この種の攻撃にはハッカー側にある程度のスキルが必要であり、攻撃者が操作および逆シリアル化されたデータからサーバーがどのようなコードやエクスプロイトを受け入れるかを攻撃者が学習する間、試行錯誤が必要になることもあります。とはいえ、この脆弱性は悪用されがちです。というのも、この脆弱性を悪用できるほど熟練したハッカーに潜在的に威力を与える可能性があるからです。
逆シリアル化されたデータの使用方法によっては、以前のブログで取り上げた攻撃を含め、いくつでも攻撃を仕掛けることができます。安全でない逆シリアル化は、リモートクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセス制御ハイジャック、そしてもちろん SQL や XML インジェクション攻撃への入り口となる可能性があります。これは基本的に、デシリアライズされるすべてのデータを信頼できるものとして宣言し、攻撃者が悪用を試みるきっかけとなります。
安全でない逆シリアル化の排除
安全でない逆シリアル化を防ぐために組織ができる最も安全なことは、アプリケーションが逆シリアル化されたデータを受け入れることを制限することです。ただし、このような攻撃を防ぐ方法は他にもあるため、これは不可能であるか、現実的ではないかもしれませんが、心配はいりません。
可能であれば、データを数値のようなものにサニタイズできます。これによって悪用が完全に阻止されるわけではありませんが、コードインジェクションは防げます。さらに良いのは、デジタル署名などの逆シリアル化されたデータに対して何らかの形式の整合性チェックを行うだけで、データ文字列が操作されていないことを確認できることです。また、デシリアライズ処理はすべて分離し、権限の低い環境で実行する必要があります。
これらの保護策を講じたら、失敗したすべての逆シリアル化試行と、データを逆シリアル化するコンテナまたはサーバーからのネットワークアクティビティを必ずログに記録してください。ユーザーがログでシリアル化解除エラーを 2 回以上発生させた場合は、そのユーザーが悪意のある内部関係者であるか、認証情報がハッキングされたり盗まれたりした可能性があると考えられます。逆シリアル化エラーを頻繁に引き起こすユーザーの自動ロックアウトのようなことを検討するかもしれません。
安全でない逆シリアル化に対処するためにこれらのツールのどれを使用するにしても、核となるのはユーザーによって触れたり操作されたりする可能性のあるデータであることを忘れないでください。決して信用しないでください。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
さらに読み進めるには、OWASPが何を言っているか見てみましょう 安全でない逆シリアル化について。また、新しく身につけた防御知識を、次の方法で試すこともできます 無料ショーケース サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行う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.
