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]をクリックしてください。
.png)
