Coders Conquer Security:シェアする・学ぶシリーズ - トランスポート層の保護が不十分な場合
アプリケーションサーバとそれが使用するバックエンドシステムを完全に保護したとしても、トランスポート層の保護が不十分であれば、通信は盗聴される可能性があります。物理的な世界では、装甲車を使ってハードカレンシーを移動させるのは、移動中の保護のためです。お店や銀行がどんなに安全であっても、そこで作られたお金がゴルフカートに積まれて街中を移動するのでは意味がありません。
これはサイバー領域のトランスポート層にも同じことが言えます。アプリケーションが安全であっても、そこに入ってくる情報が無防備な状態で送信されると、致命的な脆弱性が生じます。また、一部のアプリケーションでは、他のサーバーやデータベースにも情報を送信する場合、第二の脆弱性があります。そのような情報は、取引を盗み見ることに関係のない内部の人間にさらされる可能性があります。
ユーザーとデータを完全に保護するには、トランスポート層を保護する必要があります。そうすることで初めて、最後から最後までのトランザクション全体を完全に保護することができます。
このエピソードでは、以下のことを学びます。
- 不十分なトランスポート層保護をハッカーが利用する方法
- トランスポート層を保護しないことがなぜ危険なのか
- アプリケーションやサーバーに入る、または通過するすべてのデータのトランスポートを保護するために何ができるのか。
攻撃者はどのようにして不十分なトランスポート層保護を利用するのか？
トランスポート層の保護が不十分な場合、データストリーム内の2つのポイントで攻撃を受ける可能性があります。最も悪用されやすいのは、ユーザーとアプリケーションサーバの間です。情報が平文で送信されたり、暗号化が不十分だったりすると、ハッカーはその情報を監視したり、盗んだり、変更したりすることができます。これにより、ハッカーはユーザーのクレジットカードやログイン情報など、アプリケーションサーバに送信されたあらゆる情報を盗むことができるかもしれません。たとえサーバ自体が安全であっても、サーバとユーザの間の安全でないチャネルを監視するハッカーは、多くの情報にほぼ無制限にアクセスできる可能性があります。
次に、アプリケーションと他のネットワークとの間のトランスポート層が、保護されていないことがよくあります。例えば、アプリケーションサーバがオンラインショッピングの注文を処理してフルフィルメントシステムに送ったり、データを単純にデータベースにオフロードして保存したりする場合があります。これらの内部チャネルが保護されていない場合、内部のユーザーがその情報を見ることができる可能性があります。
すべての社内ユーザーが善良な人間であると信じたいところですが、実際には、多くの業界でインサイダーの脅威が増加しています。インサイダーは、攻撃者や競合他社のために機密情報を収集する見返りに、賄賂を受け取っていることが明らかになっています。また、何千枚もの有効なクレジットカードなどにアクセスできることは、無視できないほど魅力的なことかもしれません。
攻撃技術の面では、保護されていない通信を傍受することはそれほど難しくありません。低レベルのハッカーでも、暗号化されていないデータストリームに対して中間者攻撃を行う方法を知っています。もし知らなくても、ネット上には30分以内にトレーニングできるビデオがあります。
トランスポートレイヤー保護が不十分な脆弱性はなぜ危険なのか？
トランスポート層の保護が不十分または存在しないことは、ハッカーが機密情報を極めて容易に収集できるようになるため危険です。ハッカーは、アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はありません。アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はなく、中間者攻撃を仕掛けて、ユーザからサーバに送信される情報をすべて読み取るだけでよいのです。その中には、ユーザー名やパスワードも含まれており、将来、有効な認証情報を使ってセキュリティを回避するために使用することができます。アプリケーションによっては、クレジットカード情報やその他のユーザーの個人情報も含まれることがあります。
そして重要なのは、これらのスヌーピングがすべてネットワークの外で行われているということです。安全でないトランスポートチャネルを使用している場合、誰かがその情報を取得しているかどうかを知る方法はありません。通常、最初の兆候は、多くのユーザーがアカウントの漏洩やクレジットカードの購入を報告し始めたときであり、共通の要因は、アプリケーションが「良い場所ではない」ということです。また、ハッカーは情報を入手した後に、例えば配送先の住所を変更したり、ユーザーに渡す前にサーバーのレスポンスに悪意のあるスクリプトを挿入したりして、情報を改ざんすることができます。
バックエンドでは、トランスポート層のセキュリティを確保できないと、内部の人間にデータが公開されてしまいます。内部の人間がトランスポート層を盗み見ることは、外部からのハッカーが同じことをするのに比べれば、おそらくはるかに少ないでしょう。なぜなら、内部の脅威は、ユーザーデータだけでなく、パケットを送信する前にアプリケーションサーバーによって追加された独自の情報も見ることができるからです。
トランスポートレイヤープロテクションの不十分な脆弱性の解消
トランスポート層の保護が不十分だと危険ですが、すべてのトランスポートチャネルを適切に保護することは、それほど難しいことではありません。まず、バックエンドのインフラから始める。バックエンドは HTTPS のみを使用し、HTTPS と HTTP が混在しないように注意する。最後に、有効な SSL 証明書を最低 2048 ビットの鍵サイズで維持し、すべてのユーザに HTTP Strict Transport Security (HSTS) で保護されたブラウザを使用して対話することを強制します。
インフラが整備されたら、開発者はトランスポート層を保護するために強力なプロトコルを使用する必要があります。理想的にはTLS 1.2を使用すべきですが、どうしても必要な場合はTLS 1.1や1.0でも構いません。インフラが整備されたら、SSLv2のような弱いプロトコルは完全に無効化し、決してサポートしないようにしてください。
また、バックエンドの暗号が十分に強力なものであることにも注意を払う必要があります。理想的には、セッションキーの最小サイズは128ビットです。プロトコルと同様に、DES や RC4-40 のような弱い暗号アルゴリズムのサポートは無効にすべきです。最後に、サーバ自体と、サーバに出入りするすべてのデータパスの両方が十分に保護されるまで、アプリケーションを真に安全だと考えてはいけません。
不十分なトランスポートレイヤー保護の脆弱性に関する詳細情報
さらに詳しく知りたい方は、OWASPguide to protectingtransport layersをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
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 の共同設立者です。
アプリケーションサーバとそれが使用するバックエンドシステムを完全に保護したとしても、トランスポート層の保護が不十分であれば、通信は盗聴される可能性があります。物理的な世界では、装甲車を使ってハードカレンシーを移動させるのは、移動中の保護のためです。お店や銀行がどんなに安全であっても、そこで作られたお金がゴルフカートに積まれて街中を移動するのでは意味がありません。
これはサイバー領域のトランスポート層にも同じことが言えます。アプリケーションが安全であっても、そこに入ってくる情報が無防備な状態で送信されると、致命的な脆弱性が生じます。また、一部のアプリケーションでは、他のサーバーやデータベースにも情報を送信する場合、第二の脆弱性があります。そのような情報は、取引を盗み見ることに関係のない内部の人間にさらされる可能性があります。
ユーザーとデータを完全に保護するには、トランスポート層を保護する必要があります。そうすることで初めて、最後から最後までのトランザクション全体を完全に保護することができます。
このエピソードでは、以下のことを学びます。
- 不十分なトランスポート層保護をハッカーが利用する方法
- トランスポート層を保護しないことがなぜ危険なのか
- アプリケーションやサーバーに入る、または通過するすべてのデータのトランスポートを保護するために何ができるのか。
攻撃者はどのようにして不十分なトランスポート層保護を利用するのか？
トランスポート層の保護が不十分な場合、データストリーム内の2つのポイントで攻撃を受ける可能性があります。最も悪用されやすいのは、ユーザーとアプリケーションサーバの間です。情報が平文で送信されたり、暗号化が不十分だったりすると、ハッカーはその情報を監視したり、盗んだり、変更したりすることができます。これにより、ハッカーはユーザーのクレジットカードやログイン情報など、アプリケーションサーバに送信されたあらゆる情報を盗むことができるかもしれません。たとえサーバ自体が安全であっても、サーバとユーザの間の安全でないチャネルを監視するハッカーは、多くの情報にほぼ無制限にアクセスできる可能性があります。
次に、アプリケーションと他のネットワークとの間のトランスポート層が、保護されていないことがよくあります。例えば、アプリケーションサーバがオンラインショッピングの注文を処理してフルフィルメントシステムに送ったり、データを単純にデータベースにオフロードして保存したりする場合があります。これらの内部チャネルが保護されていない場合、内部のユーザーがその情報を見ることができる可能性があります。
すべての社内ユーザーが善良な人間であると信じたいところですが、実際には、多くの業界でインサイダーの脅威が増加しています。インサイダーは、攻撃者や競合他社のために機密情報を収集する見返りに、賄賂を受け取っていることが明らかになっています。また、何千枚もの有効なクレジットカードなどにアクセスできることは、無視できないほど魅力的なことかもしれません。
攻撃技術の面では、保護されていない通信を傍受することはそれほど難しくありません。低レベルのハッカーでも、暗号化されていないデータストリームに対して中間者攻撃を行う方法を知っています。もし知らなくても、ネット上には30分以内にトレーニングできるビデオがあります。
トランスポートレイヤー保護が不十分な脆弱性はなぜ危険なのか？
トランスポート層の保護が不十分または存在しないことは、ハッカーが機密情報を極めて容易に収集できるようになるため危険です。ハッカーは、アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はありません。アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はなく、中間者攻撃を仕掛けて、ユーザからサーバに送信される情報をすべて読み取るだけでよいのです。その中には、ユーザー名やパスワードも含まれており、将来、有効な認証情報を使ってセキュリティを回避するために使用することができます。アプリケーションによっては、クレジットカード情報やその他のユーザーの個人情報も含まれることがあります。
そして重要なのは、これらのスヌーピングがすべてネットワークの外で行われているということです。安全でないトランスポートチャネルを使用している場合、誰かがその情報を取得しているかどうかを知る方法はありません。通常、最初の兆候は、多くのユーザーがアカウントの漏洩やクレジットカードの購入を報告し始めたときであり、共通の要因は、アプリケーションが「良い場所ではない」ということです。また、ハッカーは情報を入手した後に、例えば配送先の住所を変更したり、ユーザーに渡す前にサーバーのレスポンスに悪意のあるスクリプトを挿入したりして、情報を改ざんすることができます。
バックエンドでは、トランスポート層のセキュリティを確保できないと、内部の人間にデータが公開されてしまいます。内部の人間がトランスポート層を盗み見ることは、外部からのハッカーが同じことをするのに比べれば、おそらくはるかに少ないでしょう。なぜなら、内部の脅威は、ユーザーデータだけでなく、パケットを送信する前にアプリケーションサーバーによって追加された独自の情報も見ることができるからです。
トランスポートレイヤープロテクションの不十分な脆弱性の解消
トランスポート層の保護が不十分だと危険ですが、すべてのトランスポートチャネルを適切に保護することは、それほど難しいことではありません。まず、バックエンドのインフラから始める。バックエンドは HTTPS のみを使用し、HTTPS と HTTP が混在しないように注意する。最後に、有効な SSL 証明書を最低 2048 ビットの鍵サイズで維持し、すべてのユーザに HTTP Strict Transport Security (HSTS) で保護されたブラウザを使用して対話することを強制します。
インフラが整備されたら、開発者はトランスポート層を保護するために強力なプロトコルを使用する必要があります。理想的にはTLS 1.2を使用すべきですが、どうしても必要な場合はTLS 1.1や1.0でも構いません。インフラが整備されたら、SSLv2のような弱いプロトコルは完全に無効化し、決してサポートしないようにしてください。
また、バックエンドの暗号が十分に強力なものであることにも注意を払う必要があります。理想的には、セッションキーの最小サイズは128ビットです。プロトコルと同様に、DES や RC4-40 のような弱い暗号アルゴリズムのサポートは無効にすべきです。最後に、サーバ自体と、サーバに出入りするすべてのデータパスの両方が十分に保護されるまで、アプリケーションを真に安全だと考えてはいけません。
不十分なトランスポートレイヤー保護の脆弱性に関する詳細情報
さらに詳しく知りたい方は、OWASPguide to protectingtransport layersをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
アプリケーションサーバとそれが使用するバックエンドシステムを完全に保護したとしても、トランスポート層の保護が不十分であれば、通信は盗聴される可能性があります。物理的な世界では、装甲車を使ってハードカレンシーを移動させるのは、移動中の保護のためです。お店や銀行がどんなに安全であっても、そこで作られたお金がゴルフカートに積まれて街中を移動するのでは意味がありません。
これはサイバー領域のトランスポート層にも同じことが言えます。アプリケーションが安全であっても、そこに入ってくる情報が無防備な状態で送信されると、致命的な脆弱性が生じます。また、一部のアプリケーションでは、他のサーバーやデータベースにも情報を送信する場合、第二の脆弱性があります。そのような情報は、取引を盗み見ることに関係のない内部の人間にさらされる可能性があります。
ユーザーとデータを完全に保護するには、トランスポート層を保護する必要があります。そうすることで初めて、最後から最後までのトランザクション全体を完全に保護することができます。
このエピソードでは、以下のことを学びます。
- 不十分なトランスポート層保護をハッカーが利用する方法
- トランスポート層を保護しないことがなぜ危険なのか
- アプリケーションやサーバーに入る、または通過するすべてのデータのトランスポートを保護するために何ができるのか。
攻撃者はどのようにして不十分なトランスポート層保護を利用するのか？
トランスポート層の保護が不十分な場合、データストリーム内の2つのポイントで攻撃を受ける可能性があります。最も悪用されやすいのは、ユーザーとアプリケーションサーバの間です。情報が平文で送信されたり、暗号化が不十分だったりすると、ハッカーはその情報を監視したり、盗んだり、変更したりすることができます。これにより、ハッカーはユーザーのクレジットカードやログイン情報など、アプリケーションサーバに送信されたあらゆる情報を盗むことができるかもしれません。たとえサーバ自体が安全であっても、サーバとユーザの間の安全でないチャネルを監視するハッカーは、多くの情報にほぼ無制限にアクセスできる可能性があります。
次に、アプリケーションと他のネットワークとの間のトランスポート層が、保護されていないことがよくあります。例えば、アプリケーションサーバがオンラインショッピングの注文を処理してフルフィルメントシステムに送ったり、データを単純にデータベースにオフロードして保存したりする場合があります。これらの内部チャネルが保護されていない場合、内部のユーザーがその情報を見ることができる可能性があります。
すべての社内ユーザーが善良な人間であると信じたいところですが、実際には、多くの業界でインサイダーの脅威が増加しています。インサイダーは、攻撃者や競合他社のために機密情報を収集する見返りに、賄賂を受け取っていることが明らかになっています。また、何千枚もの有効なクレジットカードなどにアクセスできることは、無視できないほど魅力的なことかもしれません。
攻撃技術の面では、保護されていない通信を傍受することはそれほど難しくありません。低レベルのハッカーでも、暗号化されていないデータストリームに対して中間者攻撃を行う方法を知っています。もし知らなくても、ネット上には30分以内にトレーニングできるビデオがあります。
トランスポートレイヤー保護が不十分な脆弱性はなぜ危険なのか？
トランスポート層の保護が不十分または存在しないことは、ハッカーが機密情報を極めて容易に収集できるようになるため危険です。ハッカーは、アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はありません。アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はなく、中間者攻撃を仕掛けて、ユーザからサーバに送信される情報をすべて読み取るだけでよいのです。その中には、ユーザー名やパスワードも含まれており、将来、有効な認証情報を使ってセキュリティを回避するために使用することができます。アプリケーションによっては、クレジットカード情報やその他のユーザーの個人情報も含まれることがあります。
そして重要なのは、これらのスヌーピングがすべてネットワークの外で行われているということです。安全でないトランスポートチャネルを使用している場合、誰かがその情報を取得しているかどうかを知る方法はありません。通常、最初の兆候は、多くのユーザーがアカウントの漏洩やクレジットカードの購入を報告し始めたときであり、共通の要因は、アプリケーションが「良い場所ではない」ということです。また、ハッカーは情報を入手した後に、例えば配送先の住所を変更したり、ユーザーに渡す前にサーバーのレスポンスに悪意のあるスクリプトを挿入したりして、情報を改ざんすることができます。
バックエンドでは、トランスポート層のセキュリティを確保できないと、内部の人間にデータが公開されてしまいます。内部の人間がトランスポート層を盗み見ることは、外部からのハッカーが同じことをするのに比べれば、おそらくはるかに少ないでしょう。なぜなら、内部の脅威は、ユーザーデータだけでなく、パケットを送信する前にアプリケーションサーバーによって追加された独自の情報も見ることができるからです。
トランスポートレイヤープロテクションの不十分な脆弱性の解消
トランスポート層の保護が不十分だと危険ですが、すべてのトランスポートチャネルを適切に保護することは、それほど難しいことではありません。まず、バックエンドのインフラから始める。バックエンドは HTTPS のみを使用し、HTTPS と HTTP が混在しないように注意する。最後に、有効な SSL 証明書を最低 2048 ビットの鍵サイズで維持し、すべてのユーザに HTTP Strict Transport Security (HSTS) で保護されたブラウザを使用して対話することを強制します。
インフラが整備されたら、開発者はトランスポート層を保護するために強力なプロトコルを使用する必要があります。理想的にはTLS 1.2を使用すべきですが、どうしても必要な場合はTLS 1.1や1.0でも構いません。インフラが整備されたら、SSLv2のような弱いプロトコルは完全に無効化し、決してサポートしないようにしてください。
また、バックエンドの暗号が十分に強力なものであることにも注意を払う必要があります。理想的には、セッションキーの最小サイズは128ビットです。プロトコルと同様に、DES や RC4-40 のような弱い暗号アルゴリズムのサポートは無効にすべきです。最後に、サーバ自体と、サーバに出入りするすべてのデータパスの両方が十分に保護されるまで、アプリケーションを真に安全だと考えてはいけません。
不十分なトランスポートレイヤー保護の脆弱性に関する詳細情報
さらに詳しく知りたい方は、OWASPguide to protectingtransport layersをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
アプリケーションサーバとそれが使用するバックエンドシステムを完全に保護したとしても、トランスポート層の保護が不十分であれば、通信は盗聴される可能性があります。物理的な世界では、装甲車を使ってハードカレンシーを移動させるのは、移動中の保護のためです。お店や銀行がどんなに安全であっても、そこで作られたお金がゴルフカートに積まれて街中を移動するのでは意味がありません。
これはサイバー領域のトランスポート層にも同じことが言えます。アプリケーションが安全であっても、そこに入ってくる情報が無防備な状態で送信されると、致命的な脆弱性が生じます。また、一部のアプリケーションでは、他のサーバーやデータベースにも情報を送信する場合、第二の脆弱性があります。そのような情報は、取引を盗み見ることに関係のない内部の人間にさらされる可能性があります。
ユーザーとデータを完全に保護するには、トランスポート層を保護する必要があります。そうすることで初めて、最後から最後までのトランザクション全体を完全に保護することができます。
このエピソードでは、以下のことを学びます。
- 不十分なトランスポート層保護をハッカーが利用する方法
- トランスポート層を保護しないことがなぜ危険なのか
- アプリケーションやサーバーに入る、または通過するすべてのデータのトランスポートを保護するために何ができるのか。
攻撃者はどのようにして不十分なトランスポート層保護を利用するのか？
トランスポート層の保護が不十分な場合、データストリーム内の2つのポイントで攻撃を受ける可能性があります。最も悪用されやすいのは、ユーザーとアプリケーションサーバの間です。情報が平文で送信されたり、暗号化が不十分だったりすると、ハッカーはその情報を監視したり、盗んだり、変更したりすることができます。これにより、ハッカーはユーザーのクレジットカードやログイン情報など、アプリケーションサーバに送信されたあらゆる情報を盗むことができるかもしれません。たとえサーバ自体が安全であっても、サーバとユーザの間の安全でないチャネルを監視するハッカーは、多くの情報にほぼ無制限にアクセスできる可能性があります。
次に、アプリケーションと他のネットワークとの間のトランスポート層が、保護されていないことがよくあります。例えば、アプリケーションサーバがオンラインショッピングの注文を処理してフルフィルメントシステムに送ったり、データを単純にデータベースにオフロードして保存したりする場合があります。これらの内部チャネルが保護されていない場合、内部のユーザーがその情報を見ることができる可能性があります。
すべての社内ユーザーが善良な人間であると信じたいところですが、実際には、多くの業界でインサイダーの脅威が増加しています。インサイダーは、攻撃者や競合他社のために機密情報を収集する見返りに、賄賂を受け取っていることが明らかになっています。また、何千枚もの有効なクレジットカードなどにアクセスできることは、無視できないほど魅力的なことかもしれません。
攻撃技術の面では、保護されていない通信を傍受することはそれほど難しくありません。低レベルのハッカーでも、暗号化されていないデータストリームに対して中間者攻撃を行う方法を知っています。もし知らなくても、ネット上には30分以内にトレーニングできるビデオがあります。
トランスポートレイヤー保護が不十分な脆弱性はなぜ危険なのか？
トランスポート層の保護が不十分または存在しないことは、ハッカーが機密情報を極めて容易に収集できるようになるため危険です。ハッカーは、アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はありません。アプリケーションサーバに侵入したり、ネットワークをハッキングしたりする必要はなく、中間者攻撃を仕掛けて、ユーザからサーバに送信される情報をすべて読み取るだけでよいのです。その中には、ユーザー名やパスワードも含まれており、将来、有効な認証情報を使ってセキュリティを回避するために使用することができます。アプリケーションによっては、クレジットカード情報やその他のユーザーの個人情報も含まれることがあります。
そして重要なのは、これらのスヌーピングがすべてネットワークの外で行われているということです。安全でないトランスポートチャネルを使用している場合、誰かがその情報を取得しているかどうかを知る方法はありません。通常、最初の兆候は、多くのユーザーがアカウントの漏洩やクレジットカードの購入を報告し始めたときであり、共通の要因は、アプリケーションが「良い場所ではない」ということです。また、ハッカーは情報を入手した後に、例えば配送先の住所を変更したり、ユーザーに渡す前にサーバーのレスポンスに悪意のあるスクリプトを挿入したりして、情報を改ざんすることができます。
バックエンドでは、トランスポート層のセキュリティを確保できないと、内部の人間にデータが公開されてしまいます。内部の人間がトランスポート層を盗み見ることは、外部からのハッカーが同じことをするのに比べれば、おそらくはるかに少ないでしょう。なぜなら、内部の脅威は、ユーザーデータだけでなく、パケットを送信する前にアプリケーションサーバーによって追加された独自の情報も見ることができるからです。
トランスポートレイヤープロテクションの不十分な脆弱性の解消
トランスポート層の保護が不十分だと危険ですが、すべてのトランスポートチャネルを適切に保護することは、それほど難しいことではありません。まず、バックエンドのインフラから始める。バックエンドは HTTPS のみを使用し、HTTPS と HTTP が混在しないように注意する。最後に、有効な SSL 証明書を最低 2048 ビットの鍵サイズで維持し、すべてのユーザに HTTP Strict Transport Security (HSTS) で保護されたブラウザを使用して対話することを強制します。
インフラが整備されたら、開発者はトランスポート層を保護するために強力なプロトコルを使用する必要があります。理想的にはTLS 1.2を使用すべきですが、どうしても必要な場合はTLS 1.1や1.0でも構いません。インフラが整備されたら、SSLv2のような弱いプロトコルは完全に無効化し、決してサポートしないようにしてください。
また、バックエンドの暗号が十分に強力なものであることにも注意を払う必要があります。理想的には、セッションキーの最小サイズは128ビットです。プロトコルと同様に、DES や RC4-40 のような弱い暗号アルゴリズムのサポートは無効にすべきです。最後に、サーバ自体と、サーバに出入りするすべてのデータパスの両方が十分に保護されるまで、アプリケーションを真に安全だと考えてはいけません。
不十分なトランスポートレイヤー保護の脆弱性に関する詳細情報
さらに詳しく知りたい方は、OWASPguide to protectingtransport layersをご覧ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御の知識を試すこともできます。この脆弱性やその他の脅威の対策についての詳細は、Secure Code Warrior ブログをご覧ください。
始めるためのリソース
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.