コーダーがセキュリティを征服：共有して学ぶシリーズ-未検証のリダイレクトと転送
未検証のリダイレクトや転送を処理できるようにウェブサイトやアプリケーションをコーディングすることは、ユーザーと組織の両方にとって非常に危険です。このよくある間違いは、フィッシング詐欺を企て、通常は制限されているページや情報へのアクセスを狙うハッカーによって悪用されることがよくあります。
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 schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
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プラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
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プラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
未検証のリダイレクトと転送はきっぱりと処理してください。当社のゲーミフィケーション・トレーニング・プラットフォームで、新しい知識を応用してスキルをテストしましょう。 [ここから始める]
目次
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
