Coders Conquer Security:シェアして学ぶシリーズ - 無効なリダイレクトとフォワード
Webサイトやアプリケーションで、妥当性のないリダイレクトや転送を処理する機能をコード化することは、ユーザーにとっても組織にとっても非常に危険です。この一般的なミスは、フィッシング詐欺や、通常は制限されているページや情報へのアクセスを狙うハッカーによく利用されます。
ウェブアプリケーションがユーザーを新しいページに転送するように設計されている場合、そのリクエストが操作されたり乗っ取られたりする危険性があります。これは、転送パラメータが意図しない目的地を指すのを防ぐための検証プロセスがない場合に起こります。
良いニュースは、検証されていないリダイレクトやフォワードは、お客様の環境から排除するのが容易な脆弱性の一つであるということです。排除した後は、いくつかの簡単な手順を踏むことで、今後このような脆弱性が発生しないようにすることができます。
このエピソードでは、以下のことを学びます。
- 無効なリダイレクトとフォワードの脆弱性を利用するハッカーの手口
- 検証されていないリダイレクトやフォワードを許可することが危険な理由
- この問題を発見し、解決するために採用できる方針と技術。
攻撃者はどのようにして無効なリダイレクトやフォワードを利用するのか？
攻撃者は、まず、ユーザを特定のページに転送するように設定されているウェブアプリケーションを見つけなければなりません。転送先のページがコードの中で定義されていれば、脆弱性はありません。例えば、Javaであれば、ハイパーリンクをクリックするなどのアクションを必要とせずに、ユーザを新しい場所に送るための安全で事前に定義された方法となります。
response.sendRedirect("http://www.knownsafesite.com")。
この脆弱性は、リダイレクトのためにユーザーの入力を受け付けるようにサイトがプログラムされている場合や、別のソースから情報を取得するためにパラメータをオープンにしている場合に発生します。例えば、開発者は「url'GET」というパラメータを使用することができます。
response.sendRedirect(request.getParameter("url"));
これにより、柔軟性が増す一方で、検証されていないリダイレクトとフォワードの脆弱性が生じます。ハッカーは、フォワードスラッシュの後に情報を追加することで、任意のサイトへのリダイレクトを引き起こすことができます（おそらくフィッシングメールの一部として）。ユーザーは、リンクの最初の部分に信頼できるドメインを見て、そのウェブサイトがハッカーのサイトに転送される可能性があることに気づきません。
なぜ無効なリダイレクトやフォワードは危険なのか？
検証されていないリダイレクトやフォワードを許可することでもたらされる危険性は大きいものです。ユーザーにとっての最大の危険は、フィッシング攻撃の被害に遭うことです。ユーザーはトップレベルのURLを目にするため、フィッシングメールなどを信用してリンクをクリックしてしまう可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その欺瞞は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはないでしょう。
無効なリダイレクトとフォワードがもたらす脅威の除去
無効なリダイレクトやフォワードは、アプリケーションの開発中に発生します。事後的に排除することもできますが、最も簡単な方法は、そもそもリダイレクトや転送の機能の一部として、ユーザのパラメータやオープンストリングを許可しないことです。代わりに、ユーザーが転送されるURLを厳密に定義することで、変数を排除し、攻撃者が操作する余地をなくすことができます。さらに言えば、リダイレクトやフォワードを一切使用しないことも検討してください。
リダイレクトやフォワードのプロセスで変数を使わないようにする方法がどうしてもない場合は、リダイレクト先が有効な目的地の1つであることを確認するための検証プロセスを導入する必要があります。最後に、実際のURLではなくマッピング値を使用することです。ハッカーは代わりにURL情報を使おうとしますし、たとえマッピングスキームが使われていると疑っても、それを推測することはできないでしょう。
無効なリダイレクトとフォワードに関する詳細情報
さらに詳しく知りたい方は、OWASP のリファレンスページである unvalidated redirects and forwards をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
検証されていないリダイレクトやフォワードを徹底的に排除します。新しい知識を活用し、ゲーム性のあるトレーニングプラットフォームで自分のスキルを試してみましょう。 [Start Here]をクリックしてください。
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 の共同設立者です。
Webサイトやアプリケーションで、妥当性のないリダイレクトや転送を処理する機能をコード化することは、ユーザーにとっても組織にとっても非常に危険です。この一般的なミスは、フィッシング詐欺や、通常は制限されているページや情報へのアクセスを狙うハッカーによく利用されます。
ウェブアプリケーションがユーザーを新しいページに転送するように設計されている場合、そのリクエストが操作されたり乗っ取られたりする危険性があります。これは、転送パラメータが意図しない目的地を指すのを防ぐための検証プロセスがない場合に起こります。
良いニュースは、検証されていないリダイレクトやフォワードは、お客様の環境から排除するのが容易な脆弱性の一つであるということです。排除した後は、いくつかの簡単な手順を踏むことで、今後このような脆弱性が発生しないようにすることができます。
このエピソードでは、以下のことを学びます。
- 無効なリダイレクトとフォワードの脆弱性を利用するハッカーの手口
- 検証されていないリダイレクトやフォワードを許可することが危険な理由
- この問題を発見し、解決するために採用できる方針と技術。
攻撃者はどのようにして無効なリダイレクトやフォワードを利用するのか？
攻撃者は、まず、ユーザを特定のページに転送するように設定されているウェブアプリケーションを見つけなければなりません。転送先のページがコードの中で定義されていれば、脆弱性はありません。例えば、Javaであれば、ハイパーリンクをクリックするなどのアクションを必要とせずに、ユーザを新しい場所に送るための安全で事前に定義された方法となります。
response.sendRedirect("http://www.knownsafesite.com")。
この脆弱性は、リダイレクトのためにユーザーの入力を受け付けるようにサイトがプログラムされている場合や、別のソースから情報を取得するためにパラメータをオープンにしている場合に発生します。例えば、開発者は「url'GET」というパラメータを使用することができます。
response.sendRedirect(request.getParameter("url"));
これにより、柔軟性が増す一方で、検証されていないリダイレクトとフォワードの脆弱性が生じます。ハッカーは、フォワードスラッシュの後に情報を追加することで、任意のサイトへのリダイレクトを引き起こすことができます（おそらくフィッシングメールの一部として）。ユーザーは、リンクの最初の部分に信頼できるドメインを見て、そのウェブサイトがハッカーのサイトに転送される可能性があることに気づきません。
なぜ無効なリダイレクトやフォワードは危険なのか？
検証されていないリダイレクトやフォワードを許可することでもたらされる危険性は大きいものです。ユーザーにとっての最大の危険は、フィッシング攻撃の被害に遭うことです。ユーザーはトップレベルのURLを目にするため、フィッシングメールなどを信用してリンクをクリックしてしまう可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その欺瞞は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはないでしょう。
無効なリダイレクトとフォワードがもたらす脅威の除去
無効なリダイレクトやフォワードは、アプリケーションの開発中に発生します。事後的に排除することもできますが、最も簡単な方法は、そもそもリダイレクトや転送の機能の一部として、ユーザのパラメータやオープンストリングを許可しないことです。代わりに、ユーザーが転送されるURLを厳密に定義することで、変数を排除し、攻撃者が操作する余地をなくすことができます。さらに言えば、リダイレクトやフォワードを一切使用しないことも検討してください。
リダイレクトやフォワードのプロセスで変数を使わないようにする方法がどうしてもない場合は、リダイレクト先が有効な目的地の1つであることを確認するための検証プロセスを導入する必要があります。最後に、実際のURLではなくマッピング値を使用することです。ハッカーは代わりにURL情報を使おうとしますし、たとえマッピングスキームが使われていると疑っても、それを推測することはできないでしょう。
無効なリダイレクトとフォワードに関する詳細情報
さらに詳しく知りたい方は、OWASP のリファレンスページである unvalidated redirects and forwards をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
検証されていないリダイレクトやフォワードを徹底的に排除します。新しい知識を活用し、ゲーム性のあるトレーニングプラットフォームで自分のスキルを試してみましょう。 [Start Here]をクリックしてください。
Webサイトやアプリケーションで、妥当性のないリダイレクトや転送を処理する機能をコード化することは、ユーザーにとっても組織にとっても非常に危険です。この一般的なミスは、フィッシング詐欺や、通常は制限されているページや情報へのアクセスを狙うハッカーによく利用されます。
ウェブアプリケーションがユーザーを新しいページに転送するように設計されている場合、そのリクエストが操作されたり乗っ取られたりする危険性があります。これは、転送パラメータが意図しない目的地を指すのを防ぐための検証プロセスがない場合に起こります。
良いニュースは、検証されていないリダイレクトやフォワードは、お客様の環境から排除するのが容易な脆弱性の一つであるということです。排除した後は、いくつかの簡単な手順を踏むことで、今後このような脆弱性が発生しないようにすることができます。
このエピソードでは、以下のことを学びます。
- 無効なリダイレクトとフォワードの脆弱性を利用するハッカーの手口
- 検証されていないリダイレクトやフォワードを許可することが危険な理由
- この問題を発見し、解決するために採用できる方針と技術。
攻撃者はどのようにして無効なリダイレクトやフォワードを利用するのか？
攻撃者は、まず、ユーザを特定のページに転送するように設定されているウェブアプリケーションを見つけなければなりません。転送先のページがコードの中で定義されていれば、脆弱性はありません。例えば、Javaであれば、ハイパーリンクをクリックするなどのアクションを必要とせずに、ユーザを新しい場所に送るための安全で事前に定義された方法となります。
response.sendRedirect("http://www.knownsafesite.com")。
この脆弱性は、リダイレクトのためにユーザーの入力を受け付けるようにサイトがプログラムされている場合や、別のソースから情報を取得するためにパラメータをオープンにしている場合に発生します。例えば、開発者は「url'GET」というパラメータを使用することができます。
response.sendRedirect(request.getParameter("url"));
これにより、柔軟性が増す一方で、検証されていないリダイレクトとフォワードの脆弱性が生じます。ハッカーは、フォワードスラッシュの後に情報を追加することで、任意のサイトへのリダイレクトを引き起こすことができます（おそらくフィッシングメールの一部として）。ユーザーは、リンクの最初の部分に信頼できるドメインを見て、そのウェブサイトがハッカーのサイトに転送される可能性があることに気づきません。
なぜ無効なリダイレクトやフォワードは危険なのか？
検証されていないリダイレクトやフォワードを許可することでもたらされる危険性は大きいものです。ユーザーにとっての最大の危険は、フィッシング攻撃の被害に遭うことです。ユーザーはトップレベルのURLを目にするため、フィッシングメールなどを信用してリンクをクリックしてしまう可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その欺瞞は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはないでしょう。
無効なリダイレクトとフォワードがもたらす脅威の除去
無効なリダイレクトやフォワードは、アプリケーションの開発中に発生します。事後的に排除することもできますが、最も簡単な方法は、そもそもリダイレクトや転送の機能の一部として、ユーザのパラメータやオープンストリングを許可しないことです。代わりに、ユーザーが転送されるURLを厳密に定義することで、変数を排除し、攻撃者が操作する余地をなくすことができます。さらに言えば、リダイレクトやフォワードを一切使用しないことも検討してください。
リダイレクトやフォワードのプロセスで変数を使わないようにする方法がどうしてもない場合は、リダイレクト先が有効な目的地の1つであることを確認するための検証プロセスを導入する必要があります。最後に、実際のURLではなくマッピング値を使用することです。ハッカーは代わりにURL情報を使おうとしますし、たとえマッピングスキームが使われていると疑っても、それを推測することはできないでしょう。
無効なリダイレクトとフォワードに関する詳細情報
さらに詳しく知りたい方は、OWASP のリファレンスページである unvalidated redirects and forwards をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
検証されていないリダイレクトやフォワードを徹底的に排除します。新しい知識を活用し、ゲーム性のあるトレーニングプラットフォームで自分のスキルを試してみましょう。 [Start Here]をクリックしてください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Webサイトやアプリケーションで、妥当性のないリダイレクトや転送を処理する機能をコード化することは、ユーザーにとっても組織にとっても非常に危険です。この一般的なミスは、フィッシング詐欺や、通常は制限されているページや情報へのアクセスを狙うハッカーによく利用されます。
ウェブアプリケーションがユーザーを新しいページに転送するように設計されている場合、そのリクエストが操作されたり乗っ取られたりする危険性があります。これは、転送パラメータが意図しない目的地を指すのを防ぐための検証プロセスがない場合に起こります。
良いニュースは、検証されていないリダイレクトやフォワードは、お客様の環境から排除するのが容易な脆弱性の一つであるということです。排除した後は、いくつかの簡単な手順を踏むことで、今後このような脆弱性が発生しないようにすることができます。
このエピソードでは、以下のことを学びます。
- 無効なリダイレクトとフォワードの脆弱性を利用するハッカーの手口
- 検証されていないリダイレクトやフォワードを許可することが危険な理由
- この問題を発見し、解決するために採用できる方針と技術。
攻撃者はどのようにして無効なリダイレクトやフォワードを利用するのか？
攻撃者は、まず、ユーザを特定のページに転送するように設定されているウェブアプリケーションを見つけなければなりません。転送先のページがコードの中で定義されていれば、脆弱性はありません。例えば、Javaであれば、ハイパーリンクをクリックするなどのアクションを必要とせずに、ユーザを新しい場所に送るための安全で事前に定義された方法となります。
response.sendRedirect("http://www.knownsafesite.com")。
この脆弱性は、リダイレクトのためにユーザーの入力を受け付けるようにサイトがプログラムされている場合や、別のソースから情報を取得するためにパラメータをオープンにしている場合に発生します。例えば、開発者は「url'GET」というパラメータを使用することができます。
response.sendRedirect(request.getParameter("url"));
これにより、柔軟性が増す一方で、検証されていないリダイレクトとフォワードの脆弱性が生じます。ハッカーは、フォワードスラッシュの後に情報を追加することで、任意のサイトへのリダイレクトを引き起こすことができます（おそらくフィッシングメールの一部として）。ユーザーは、リンクの最初の部分に信頼できるドメインを見て、そのウェブサイトがハッカーのサイトに転送される可能性があることに気づきません。
なぜ無効なリダイレクトやフォワードは危険なのか？
検証されていないリダイレクトやフォワードを許可することでもたらされる危険性は大きいものです。ユーザーにとっての最大の危険は、フィッシング攻撃の被害に遭うことです。ユーザーはトップレベルのURLを目にするため、フィッシングメールなどを信用してリンクをクリックしてしまう可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その欺瞞は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはないでしょう。
無効なリダイレクトとフォワードがもたらす脅威の除去
無効なリダイレクトやフォワードは、アプリケーションの開発中に発生します。事後的に排除することもできますが、最も簡単な方法は、そもそもリダイレクトや転送の機能の一部として、ユーザのパラメータやオープンストリングを許可しないことです。代わりに、ユーザーが転送されるURLを厳密に定義することで、変数を排除し、攻撃者が操作する余地をなくすことができます。さらに言えば、リダイレクトやフォワードを一切使用しないことも検討してください。
リダイレクトやフォワードのプロセスで変数を使わないようにする方法がどうしてもない場合は、リダイレクト先が有効な目的地の1つであることを確認するための検証プロセスを導入する必要があります。最後に、実際のURLではなくマッピング値を使用することです。ハッカーは代わりにURL情報を使おうとしますし、たとえマッピングスキームが使われていると疑っても、それを推測することはできないでしょう。
無効なリダイレクトとフォワードに関する詳細情報
さらに詳しく知りたい方は、OWASP のリファレンスページである unvalidated redirects and forwards をご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威への対策について詳しくは、Secure Code Warrior ブログをご覧ください。
検証されていないリダイレクトやフォワードを徹底的に排除します。新しい知識を活用し、ゲーム性のあるトレーニングプラットフォームで自分のスキルを試してみましょう。 [Start Here]をクリックしてください。
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、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運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
