コーダーがセキュリティを征服：共有して学ぶシリーズ-未検証のリダイレクトと転送
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
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 vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
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プラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Afficher le rapportVeuillez réserver une démonstration.
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プラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Table des matières
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior vous assiste dans la protection de votre code tout au long du cycle de vie du développement logiciel et dans la création d'une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou professionnel de la sécurité, nous vous aidons à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.[Télécharger]Ressources pour débuter
Sujets et contenu de la formation sur le code sécurisé
Notre contenu, leader dans le secteur, évolue constamment en fonction de l'environnement de développement logiciel en constante mutation, tout en tenant compte du rôle de nos clients. Il couvre tous les sujets, de l'IA à l'injection XQuery, et s'adresse à divers rôles, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Nous vous invitons à consulter le catalogue de contenu pour découvrir son contenu par sujet et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : la mission IA consistant à vaincre le boss est désormais disponible à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année sur SCW. Renforcez considérablement le développement sécurisé de l'IA en introduisant des défis de sécurité avancés en matière d'IA/LLM.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la résilience cybernétique (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent se préparer en matière de pratiques de sécurité dès la conception, de prévention des vulnérabilités et de développement des compétences des développeurs.
Facilitateur 1 : Critères de réussite prédéfinis et mesurables
Enabler 1 est le premier volet d'une série de dix intitulée « Enablers of Success » (Les catalyseurs de la réussite). Il présente comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et l'accélération des processus afin de faire évoluer le programme à long terme.
