ALBにおける無効なHTTPヘッダーの削除設定について

2025.06.18

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、「どうやって直すのか？」 という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、Application Load Balancer (ALB) が無効なHTTPヘッダーを削除するように設定されていない状態について、リスクと対策を解説します。

ポリシーの説明

Elastic Load Balancing の Security Hub コントロール – AWS Security Hub

このコントロールは、 Application Load Balancer が無効な HTTP ヘッダーを削除するように設定されているかどうかを評価します。routing.http.drop_invalid_header_fields.enabled の値が false に設定されている場合、コントロールは失敗します。

リスク

Amazon Web Services (AWS) のApplication Load Balancer (ALB) は、HTTP/HTTPSトラフィックのルーティングを担うレイヤー7ロードバランサーです。デフォルトでは、ALBは無効なHTTPヘッダー値を削除するように設定されていません。この設定がされていない場合、以下のようなセキュリティ上の重大なリスクが発生します。

  • HTTP Desync攻撃の可能性: 無効なHTTPヘッダー（特にContent-LengthとTransfer-Encodingの不整合）が存在すると、ALBとバックエンドサーバー間でリクエストの解釈にずれが生じるHTTP Desync（またはHTTP Request Smuggling）攻撃を受ける可能性があります。これにより、攻撃者はALBの解釈の差異を利用して、意図しないリクエストをバックエンドに送り込んだり、他のユーザーのリクエストをハイジャックしたりする可能性があります。
  • バックエンドサーバーへの不正なデータ注入: 不正なヘッダー値がそのままバックエンドサーバーに転送されることで、アプリケーションの脆弱性を悪用され、SQLインジェクション、クロスサイトスクリプティング (XSS)、またはその他のインジェクション攻撃につながる可能性があります。
  • コンプライアンス違反: 多くのセキュリティ規制やコンプライアンス基準（例: PCI DSS）では、アプリケーションレイヤーでの不正な入力の検証とサニタイズが求められます。無効なヘッダーを適切に処理しないことは、これらの要件に抵触する可能性があります。
  • アプリケーションの不安定性: 予期せぬ、または不正なHTTPヘッダーがバックエンドアプリケーションに到達すると、アプリケーションが正しく動作しなかったり、クラッシュしたりする原因となることがあります。

対策

Application Load Balancer (ALB) で無効なHTTPヘッダーを削除するように設定することは、HTTP Desync攻撃などのリスクを軽減し、アプリケーションのセキュリティを強化するために不可欠です。

  • desync_mitigation_mode の設定: ALBのdesync_mitigation_mode属性を**defensiveまたはstrictest**に設定します。
    • defensive (推奨): ALBがHTTP Desync攻撃に対して一般的な防御策を適用します。これにより、ほとんどの不正なリクエストがブロックされるか、安全な方法で処理されます。
    • strictest: 最も厳格なモードで、HTTP仕様に厳密に準拠しないリクエストをブロックします。これは一部の正当なクライアントからのリクエストもブロックする可能性があるため、慎重なテストが必要です。
  • ログの監視: ALBのアクセスログを有効にし、desync_mitigation_modeによってブロックまたは変更されたリクエストがないか監視します。これにより、正当なトラフィックに影響が出ていないか、または攻撃の兆候がないかを確認できます。
  • バックエンドアプリケーションの強化: ALBでの対策に加え、バックエンドアプリケーション自身も入力検証とサニタイズを徹底し、無効なヘッダーや不正な入力を適切に処理できるように設計することが重要です。
  • 定期的なテスト: 定期的にセキュリティスキャンやペネトレーションテストを実施し、ALBとバックエンドアプリケーションの間のHTTPプロトコル処理に潜在的な脆弱性がないか確認します。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、Application Load Balancerで無効なHTTPヘッダーを削除するように設定します。

  1. EC2サービスへ移動:
    • AWSコンソールにログインし、EC2サービスを開きます。
  2. ロードバランサーの選択:
    • 左側のナビゲーションペインで「ロードバランサー」を選択します。
    • 設定を変更したい「Application Load Balancer」を選択します。
  3. 属性の編集:
    • ロードバランサーの詳細ページで、「説明」タブ（または「属性」タブ）を選択します。
    • 「ロードバランサーの属性」セクションを見つけ、「属性を編集」ボタンをクリックします。
  4. Desync Mitigation Modeの設定:
    • 「Desync　緩和モード」を見つけます。
    • 「無効なヘッダーフィールドを削除」をオンにします。
    • 「変更を保存」をクリックして設定を適用します。

Terraformでの修復手順

TerraformでApplication Load BalancerのHTTPヘッダー処理を設定するには、aws_lb リソースの desync_mitigation_mode パラメータを設定します。

# Application Load Balancer (ALB) の定義
resource "aws_lb" "my_alb" {
  name               = "my-application-load-balancer"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.public_a.id, aws_subnet.public_c.id] # あなたのサブネットIDに置き換え

  # 無効なHTTPヘッダーの処理モードを設定 (推奨: defensive)
  # "defensive" は一般的な攻撃パターンに対して防御的
  # "strictest" はHTTP仕様に厳密に準拠しないリクエストをブロック (影響を考慮して使用)
  # "monitor" はログ記録のみでブロックせず
  desync_mitigation_mode = "defensive"

  enable_deletion_protection = true # 本番環境では有効化を推奨

  tags = {
    Name = "MyApplicationLoadBalancer"
  }
}

# ALBのターゲットグループの定義例
resource "aws_lb_target_group" "my_app_tg" {
  name     = "my-app-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id # あなたのVPC IDに置き換え

  health_check {
    path = "/"
    protocol = "HTTP"
    matcher = "200"
    interval = 30
    timeout = 5
    healthy_threshold = 2
    unhealthy_threshold = 2
  }
}

# ALBのリスナーの定義例
resource "aws_lb_listener" "http_listener" {
  load_balancer_arn = aws_lb.my_alb.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    target_group_arn = aws_lb_target_group.my_app_tg.arn
    type             = "forward"
  }
}

# 関連リソースの定義例 (VPC, Subnet, Security Group など)
# これらのリソースは、あなたの環境に合わせて定義または参照してください。

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "public_a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a" # あなたのリージョンに合わせて変更
  tags = {
    Name = "public-subnet-a"
  }
}

resource "aws_subnet" "public_c" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "ap-northeast-1c" # あなたのリージョンに合わせて変更
  tags = {
    Name = "public-subnet-c"
  }
}

resource "aws_security_group" "alb_sg" {
  name        = "alb-security-group"
  description = "Allow HTTP/HTTPS traffic to ALB"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # 適切なIP範囲に制限してください
  }
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # HTTPSも利用する場合
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "alb-sg"
  }
}

上記のTerraformコードでは、aws_lb リソース内で desync_mitigation_mode = "defensive" を設定しています。これにより、ALBはHTTP Desync攻撃に対して防御的な挙動をするようになります。

my-application-load-balancer やサブネットIDなどのプレースホルダーは、実際の環境に合わせて修正してください。

最後に

この記事では、Application Load Balancer (ALB) が無効なHTTPヘッダーを削除するように設定されていない状態について、リスクと対策を解説しました。desync_mitigation_modeを適切に設定することで、HTTP Desync攻撃を防ぎ、Webアプリケーションのセキュリティを大幅に向上させることができます。これは、今日の複雑なWeb環境における基本的なセキュリティ対策の一つと言えるでしょう。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。

運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る