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]をクリックしてください。
始めるためのリソース
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.
始めるためのリソース
.png)
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.