コーダーがセキュリティを征服：共有して学ぶシリーズ-未検証のリダイレクトと転送
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
Web アプリケーションがユーザーを新しいページに転送するように設計されていると、それらのリクエストが操作されたりハイジャックされたりする危険性があります。これは、転送パラメータが意図しない宛先を指すのを防ぐための検証プロセスがない場合に発生する可能性があります。
幸いなことに、未検証のリダイレクトと転送は、環境から簡単に排除できる脆弱性の1つです。いったん削除したら、いくつかの簡単な手順を実行して、今後発生しないようにすることができます。
このエピソードでは、次のことを学びます。
- ハッカーが未検証のリダイレクトと転送の脆弱性を悪用する方法
- 未検証のリダイレクトと転送を許可することが危険な理由
- この問題の発見と解決に役立つポリシーとテクニック。
攻撃者は未検証のリダイレクトや転送をどのように悪用しますか?
攻撃者はまず、特定の 1 つまたは複数のページにユーザーを転送するように設定された Web アプリケーションを見つける必要があります。宛先ページがコードで定義されていれば、脆弱性はありません。たとえば Java では、ハイパーリンクをクリックするなどの操作を一切行わなくても、ユーザーを新しい場所に誘導する安全な方法であらかじめ定義されています。
Response.senRedirect (」http://www.knownsafesite.com「);
この脆弱性は、リダイレクトのためのユーザー入力を代わりに受け入れるようにサイトがプログラムされている場合、またはパラメーターが開いたままになっている場合、たとえば別のソースから情報を取得する場合に発生します。たとえば、開発者は「URL'get」パラメーターを使用できます。
Response.sendRedirect (request.GetParameter (「url」));
これにより柔軟性が向上する一方で、未検証のリダイレクトと転送の脆弱性も生じます。ハッカーは、たとえばフィッシングメールの一部として、フォワードスラッシュの後に情報を追加して、選択したサイトへのリダイレクトをトリガーできます。ユーザーは、リンクの最初の部分で信頼されたドメインを確認しても、Web サイトがハッカーのサイトにそのドメインを転送していることに気づきません。
未検証のリダイレクトと転送はなぜそれほど危険なのですか?
未検証のリダイレクトと転送を許可することによる危険は重大な場合があります。ユーザーにとって最大の危険は、フィッシング攻撃の被害者になる可能性があることです。ユーザーは最上位の URL を見るため、フィッシングメールやその他の通信を信頼してリンクをクリックする可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その詐欺は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはありません。
未検証のリダイレクトと転送によってもたらされる脅威の排除
未検証のリダイレクトと転送は、アプリケーションの開発中に開始されます。これらは事後に削除することもできますが、最も簡単な排除方法は、そもそもリダイレクトや転送機能の一部としてユーザーパラメーターやオープンストリングを許可しないことです。その代わり、ユーザーを転送する URL を厳密に定義して、変数を排除し、攻撃者が操作する余地がないようにします。さらに良いのは、リダイレクトや転送をまったく使用しないことです。
リダイレクトまたは転送プロセスの一部として変数を使用することを避ける方法がまったくない場合は、リダイレクトが一連の有効な宛先のいずれかに送信されることを確認するための検証プロセスを導入する必要があります。最後に、実際の URL の代わりにマッピング値を使用してください。ハッカーは代わりに URL 情報を使用しようとするため、マッピングスキームが使用されていると疑っても推測できない可能性があります。
未検証のリダイレクトと転送に関する詳細情報
詳細については、OWASPをご覧ください リファレンスページ 未検証のリダイレクトと転送についてまた、新しく身につけた防御知識を、次の方法で試すこともできます。 無料デモ サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
Web アプリケーションがユーザーを新しいページに転送するように設計されていると、それらのリクエストが操作されたりハイジャックされたりする危険性があります。これは、転送パラメータが意図しない宛先を指すのを防ぐための検証プロセスがない場合に発生する可能性があります。
幸いなことに、未検証のリダイレクトと転送は、環境から簡単に排除できる脆弱性の1つです。いったん削除したら、いくつかの簡単な手順を実行して、今後発生しないようにすることができます。
このエピソードでは、次のことを学びます。
- ハッカーが未検証のリダイレクトと転送の脆弱性を悪用する方法
- 未検証のリダイレクトと転送を許可することが危険な理由
- この問題の発見と解決に役立つポリシーとテクニック。
攻撃者は未検証のリダイレクトや転送をどのように悪用しますか?
攻撃者はまず、特定の 1 つまたは複数のページにユーザーを転送するように設定された Web アプリケーションを見つける必要があります。宛先ページがコードで定義されていれば、脆弱性はありません。たとえば Java では、ハイパーリンクをクリックするなどの操作を一切行わなくても、ユーザーを新しい場所に誘導する安全な方法であらかじめ定義されています。
Response.senRedirect (」http://www.knownsafesite.com「);
この脆弱性は、リダイレクトのためのユーザー入力を代わりに受け入れるようにサイトがプログラムされている場合、またはパラメーターが開いたままになっている場合、たとえば別のソースから情報を取得する場合に発生します。たとえば、開発者は「URL'get」パラメーターを使用できます。
Response.sendRedirect (request.GetParameter (「url」));
これにより柔軟性が向上する一方で、未検証のリダイレクトと転送の脆弱性も生じます。ハッカーは、たとえばフィッシングメールの一部として、フォワードスラッシュの後に情報を追加して、選択したサイトへのリダイレクトをトリガーできます。ユーザーは、リンクの最初の部分で信頼されたドメインを確認しても、Web サイトがハッカーのサイトにそのドメインを転送していることに気づきません。
未検証のリダイレクトと転送はなぜそれほど危険なのですか?
未検証のリダイレクトと転送を許可することによる危険は重大な場合があります。ユーザーにとって最大の危険は、フィッシング攻撃の被害者になる可能性があることです。ユーザーは最上位の URL を見るため、フィッシングメールやその他の通信を信頼してリンクをクリックする可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その詐欺は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはありません。
未検証のリダイレクトと転送によってもたらされる脅威の排除
未検証のリダイレクトと転送は、アプリケーションの開発中に開始されます。これらは事後に削除することもできますが、最も簡単な排除方法は、そもそもリダイレクトや転送機能の一部としてユーザーパラメーターやオープンストリングを許可しないことです。その代わり、ユーザーを転送する URL を厳密に定義して、変数を排除し、攻撃者が操作する余地がないようにします。さらに良いのは、リダイレクトや転送をまったく使用しないことです。
リダイレクトまたは転送プロセスの一部として変数を使用することを避ける方法がまったくない場合は、リダイレクトが一連の有効な宛先のいずれかに送信されることを確認するための検証プロセスを導入する必要があります。最後に、実際の URL の代わりにマッピング値を使用してください。ハッカーは代わりに URL 情報を使用しようとするため、マッピングスキームが使用されていると疑っても推測できない可能性があります。
未検証のリダイレクトと転送に関する詳細情報
詳細については、OWASPをご覧ください リファレンスページ 未検証のリダイレクトと転送についてまた、新しく身につけた防御知識を、次の方法で試すこともできます。 無料デモ サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
Web アプリケーションがユーザーを新しいページに転送するように設計されていると、それらのリクエストが操作されたりハイジャックされたりする危険性があります。これは、転送パラメータが意図しない宛先を指すのを防ぐための検証プロセスがない場合に発生する可能性があります。
幸いなことに、未検証のリダイレクトと転送は、環境から簡単に排除できる脆弱性の1つです。いったん削除したら、いくつかの簡単な手順を実行して、今後発生しないようにすることができます。
このエピソードでは、次のことを学びます。
- ハッカーが未検証のリダイレクトと転送の脆弱性を悪用する方法
- 未検証のリダイレクトと転送を許可することが危険な理由
- この問題の発見と解決に役立つポリシーとテクニック。
攻撃者は未検証のリダイレクトや転送をどのように悪用しますか?
攻撃者はまず、特定の 1 つまたは複数のページにユーザーを転送するように設定された Web アプリケーションを見つける必要があります。宛先ページがコードで定義されていれば、脆弱性はありません。たとえば Java では、ハイパーリンクをクリックするなどの操作を一切行わなくても、ユーザーを新しい場所に誘導する安全な方法であらかじめ定義されています。
Response.senRedirect (」http://www.knownsafesite.com「);
この脆弱性は、リダイレクトのためのユーザー入力を代わりに受け入れるようにサイトがプログラムされている場合、またはパラメーターが開いたままになっている場合、たとえば別のソースから情報を取得する場合に発生します。たとえば、開発者は「URL'get」パラメーターを使用できます。
Response.sendRedirect (request.GetParameter (「url」));
これにより柔軟性が向上する一方で、未検証のリダイレクトと転送の脆弱性も生じます。ハッカーは、たとえばフィッシングメールの一部として、フォワードスラッシュの後に情報を追加して、選択したサイトへのリダイレクトをトリガーできます。ユーザーは、リンクの最初の部分で信頼されたドメインを確認しても、Web サイトがハッカーのサイトにそのドメインを転送していることに気づきません。
未検証のリダイレクトと転送はなぜそれほど危険なのですか?
未検証のリダイレクトと転送を許可することによる危険は重大な場合があります。ユーザーにとって最大の危険は、フィッシング攻撃の被害者になる可能性があることです。ユーザーは最上位の URL を見るため、フィッシングメールやその他の通信を信頼してリンクをクリックする可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その詐欺は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはありません。
未検証のリダイレクトと転送によってもたらされる脅威の排除
未検証のリダイレクトと転送は、アプリケーションの開発中に開始されます。これらは事後に削除することもできますが、最も簡単な排除方法は、そもそもリダイレクトや転送機能の一部としてユーザーパラメーターやオープンストリングを許可しないことです。その代わり、ユーザーを転送する URL を厳密に定義して、変数を排除し、攻撃者が操作する余地がないようにします。さらに良いのは、リダイレクトや転送をまったく使用しないことです。
リダイレクトまたは転送プロセスの一部として変数を使用することを避ける方法がまったくない場合は、リダイレクトが一連の有効な宛先のいずれかに送信されることを確認するための検証プロセスを導入する必要があります。最後に、実際の URL の代わりにマッピング値を使用してください。ハッカーは代わりに URL 情報を使用しようとするため、マッピングスキームが使用されていると疑っても推測できない可能性があります。
未検証のリダイレクトと転送に関する詳細情報
詳細については、OWASPをご覧ください リファレンスページ 未検証のリダイレクトと転送についてまた、新しく身につけた防御知識を、次の方法で試すこともできます。 無料デモ サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Haga clic en el siguiente enlace para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
Web アプリケーションがユーザーを新しいページに転送するように設計されていると、それらのリクエストが操作されたりハイジャックされたりする危険性があります。これは、転送パラメータが意図しない宛先を指すのを防ぐための検証プロセスがない場合に発生する可能性があります。
幸いなことに、未検証のリダイレクトと転送は、環境から簡単に排除できる脆弱性の1つです。いったん削除したら、いくつかの簡単な手順を実行して、今後発生しないようにすることができます。
このエピソードでは、次のことを学びます。
- ハッカーが未検証のリダイレクトと転送の脆弱性を悪用する方法
- 未検証のリダイレクトと転送を許可することが危険な理由
- この問題の発見と解決に役立つポリシーとテクニック。
攻撃者は未検証のリダイレクトや転送をどのように悪用しますか?
攻撃者はまず、特定の 1 つまたは複数のページにユーザーを転送するように設定された Web アプリケーションを見つける必要があります。宛先ページがコードで定義されていれば、脆弱性はありません。たとえば Java では、ハイパーリンクをクリックするなどの操作を一切行わなくても、ユーザーを新しい場所に誘導する安全な方法であらかじめ定義されています。
Response.senRedirect (」http://www.knownsafesite.com「);
この脆弱性は、リダイレクトのためのユーザー入力を代わりに受け入れるようにサイトがプログラムされている場合、またはパラメーターが開いたままになっている場合、たとえば別のソースから情報を取得する場合に発生します。たとえば、開発者は「URL'get」パラメーターを使用できます。
Response.sendRedirect (request.GetParameter (「url」));
これにより柔軟性が向上する一方で、未検証のリダイレクトと転送の脆弱性も生じます。ハッカーは、たとえばフィッシングメールの一部として、フォワードスラッシュの後に情報を追加して、選択したサイトへのリダイレクトをトリガーできます。ユーザーは、リンクの最初の部分で信頼されたドメインを確認しても、Web サイトがハッカーのサイトにそのドメインを転送していることに気づきません。
未検証のリダイレクトと転送はなぜそれほど危険なのですか?
未検証のリダイレクトと転送を許可することによる危険は重大な場合があります。ユーザーにとって最大の危険は、フィッシング攻撃の被害者になる可能性があることです。ユーザーは最上位の URL を見るため、フィッシングメールやその他の通信を信頼してリンクをクリックする可能性が高くなります。また、リダイレクト先のページが実際のページのように見える場合、その詐欺は非常に効果的です。ユーザー名、パスワード、その他の認証情報を共有しても、自分が操作されていることを疑うことはありません。
未検証のリダイレクトと転送によってもたらされる脅威の排除
未検証のリダイレクトと転送は、アプリケーションの開発中に開始されます。これらは事後に削除することもできますが、最も簡単な排除方法は、そもそもリダイレクトや転送機能の一部としてユーザーパラメーターやオープンストリングを許可しないことです。その代わり、ユーザーを転送する URL を厳密に定義して、変数を排除し、攻撃者が操作する余地がないようにします。さらに良いのは、リダイレクトや転送をまったく使用しないことです。
リダイレクトまたは転送プロセスの一部として変数を使用することを避ける方法がまったくない場合は、リダイレクトが一連の有効な宛先のいずれかに送信されることを確認するための検証プロセスを導入する必要があります。最後に、実際の URL の代わりにマッピング値を使用してください。ハッカーは代わりに URL 情報を使用しようとするため、マッピングスキームが使用されていると疑っても推測できない可能性があります。
未検証のリダイレクトと転送に関する詳細情報
詳細については、OWASPをご覧ください リファレンスページ 未検証のリダイレクトと転送についてまた、新しく身につけた防御知識を、次の方法で試すこともできます。 無料デモ サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Índice
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
