Pingora系リクエストスマグリング対策ランブック

リクエストスマグリングは、WAFの有無よりも「どこでどう解釈がズレるか」が本質です。高速プロキシ基盤（Pingora系を含む）では、性能最適化の一方で、パーサ実装差異が攻撃面になります。

本稿は、運用チーム向けに封じ込め→検証→恒久対策の順で整理したランブックです。

なぜ危険なのか

発火点は、主に以下の解釈不一致です。

• Content-Length と Transfer-Encoding の優先順位差
• 重複ヘッダや正規化ルールの差
• コネクション再利用時の境界認識差

上流は1リクエストと解釈し、下流は2リクエストと解釈することで、認可回避やキャッシュ汚染が成立します。

フェーズ1: 0〜24時間の封じ込め

1. ベンダーが示す緩和策・修正版を最優先適用
2. エッジで曖昧パターン（CL+TE等）を一時的に全面拒否
3. パーサ異常ログを高粒度で採取
4. 高リスク経路のKeep-Alive再利用を一時抑制

この段階の目的は、完璧な設計ではなく攻撃成立確率の急速低下です。

フェーズ2: 24〜72時間の検証

本番トラフィックのリプレイ＋攻撃用ペイロードで検証します。

• 中継ノード間で分割・結合の不整合がないか
• 不正チャンクや異常ヘッダ時の挙動が一貫しているか
• レイテンシSLOを許容範囲で維持できるか

修正が正しくても、前提トラフィックが違えば障害化します。

フェーズ3: パーサ契約の明文化

HTTP解釈を「暗黙知」にしないことが再発防止の要です。

• エッジ/メッシュ/ゲートウェイで共通解釈ルールを定義
• 重複ヘッダや曖昧転送構文を非許容に統一
• プロトコルダウングレード経路を可視化・監視

これにより、チーム間・製品間の挙動ドリフトを防げます。

検知設計

単一シグネチャ依存は避け、3層で見ます。

1. 既知パターン検知（シグネチャ）
2. 要求/応答の対応崩れ検知（振る舞い）
3. 到達不能経路遷移検知（経路異常）

未知変種には振る舞い検知が効きます。

長期バックログ

• CIでのパーサ差分テスト
• 曖昧構文コーパスを用いたファズ
• Ingress依存の定期更新ウィンドウ化
• セキュリティ修正適用リードタイムのSLO化

まとめ

Ingress防御は境界制御ではなく解釈整合性の運用です。契約化・差分検証・継続監視を回せる組織ほど、次の脆弱性公開時に被害を最小化できます。