投稿日: Aug 17, 2020
Application Load Balancer (ALB) および Classic Load Balancer (CLB) が HTTP Desync Mitigation Mode をサポートするようになりました。これは、HTTP Desync による問題からアプリケーションを保護する新機能です。現代のウェブアプリケーションは通常、クライアントとサーバー間の高速で信頼性の高い通信を保証する一連のプロキシで構築されています。これらのプロキシは、RFC 7230 準拠の HTTP/1.1 リクエストを解析するための標準的なメカニズムに従いますが、非準拠のリクエストを解析するときに解釈が異なる場合があります。チェーン内の異なるプロキシがリクエストの境界で一致しない可能性があり、そのため同じリクエストを処理しない可能性がある場合に、これらの解釈の違いが Desync を引き起こすことがあります。これにより、キュー内の次のリクエストの先頭に追加されてバックエンドにスマグリングされる可能性のある任意のメッセージが残る可能性があります。最終的に、リクエストスマグリングは、アプリケーションをリクエストキューまたはキャッシュポイズニングに対して脆弱にし、認証情報のハイジャックまたは不正なコマンドの実行につながる可能性があります。
Desync を軽減する唯一のオプションは、RFC に厳密に準拠するリクエストのみを許可することです。ただし、現実に行われるリクエストでは、RFC に厳密に準拠していない文字が含まれていることが往々にしてあります。その結果、厳密に準拠しているリクエストのみを許可する戦略に拘泥すると、一部の正当なユースケースで可用性のリスクが発生する可能性があります。Desync Mitigation Mode を使用すると、ALB/CLB は、アプリケーションの可用性とパフォーマンスを維持しながら、永続的なセキュリティを提供します。これを実現するために、ロードバランサーは、HTTP Desync Guardian と呼ばれる AWS Open Source ライブラリを使用して、脅威レベルに基づいてすべてのリクエストを分類します。その後、ロードバランサーを設定し、アプリケーションのセキュリティニーズに基づいて適切な軽減戦略を選択できます。この機能を使用すると、ALB または CLB は、ロードバランサーの前後両方の HTTP 脆弱性からアプリケーションへの脅威を軽減します。
Desync Mitigation Mode では、「Defensive」(防御)、「Strictest」(最も厳格)、「Monitor」(監視) の 3 つのモードから選択できます。「Defensive」(防御) モードでは、ロードバランサーは 3 つの特定のタスクを実行します。1 つ目のタスクは、RFC 7230 への準拠に関係なく、アプリケーションが既知の安全なリクエストを受信できるようにすることです。2 つ目のタスクは、RFC に準拠しておらず、既知のセキュリティ脅威であるリクエストをブロックすることです。3 つ目のタスクは、あいまいなリクエストに対する HTTP キープアライブの制限に関係なく、クライアント接続とアップストリーム接続の両方を閉じることです。あいまいなリクエストとは、RFC 7230 に準拠していないリクエストであり、プロキシやウェブサーバーによって解釈が異なるため、Desync が発生する可能性があります。「Defensive」(防御) モードは、アプリケーションの可用性を維持しながら、HTTP Desync に対する永続的なハンズフリーの軽減を提供するため、デフォルトとして選択されます。アプリケーションが RFC 7230 準拠のリクエストのみを受け取るようにする必要がある場合は、「Strictest」(最も厳格) モードを選択できます。最後に、柔軟性を実現すべく、分類に関係なく、ロードバランサーが受け取ったすべてのリクエストを背後のアプリケーションに転送する場合は、「Monitor」(監視) モードを設定することもできます。
3 つのモードすべてが ALB と CLB の両方で CloudWatch メトリクスを提供し、トラフィックからアプリケーションへの脅威レベルを集約して可視化します。ALB は、クライアントがアプリケーションにもたらす脅威を特定するためにリクエストごとの詳細な分析を実行できるアクセスログも提供します。