Pingoraのリクエストスマグリング対応: Ingress運用プレイブック

Pingora OSSで公開された複数のリクエストスマグリング脆弱性は、「高速プロキシなら安全」という思い込みを崩す出来事でした。問題の本質は単一バグではなく、プロキシとバックエンドの解釈差です。HTTPメッセージ境界の扱いが少しでもズレると、キャッシュ汚染、認可バイパス、レスポンス混線に直結します。

重要なのは、パッチ適用だけで終わらせないことです。安全な運用は、パーサー一貫性の検証、監視強化、回帰テスト、責任分界の明確化まで含めて成立します。

まず24時間でやること

緊急対応以外のIngress設定変更を凍結する
修正版への段階的アップグレードを実施する
不正フレーミング検知のメトリクスとログ粒度を引き上げる
既知のスマグリング検体をCanary/Pre-prodで再生する
キャッシュ境界と認証境界をルート単位で再監査する

この順番にする理由は、影響範囲を止めつつ、原因分析に必要な観測点を先に確保できるからです。

検知で見るべきシグナル

多くの障害で「ログはあるのに判断できない」状態になります。以下を優先すると解析精度が上がります。

4xx/5xx増加時に、受信バイト長と解釈ヘッダ数が乖離していないか
バックエンド側のパース失敗や予期しないリクエストラインの増加
パーソナライズ対象エンドポイントでの異常なキャッシュヒット
短時間接続の反復と不正Transfer-Encodingパターン

加えて、隔離環境でのサンプルパケット取得を用意すると、推測ではなく事実で議論できます。

パッチ後に必ず入れる恒久対策

1. パーサー契約テスト

Ingressと各バックエンドに同一検体を流し、「同じ境界で解釈するか」をCIで保証します。ステータスコード一致だけでは不十分です。

2. 厳格正規化ポリシー

曖昧なリクエストを早期拒否します。Content-Length競合、重複ヘッダの扱い、異常なチャンク境界を許容しない方針が有効です。

3. キャッシュ安全宣言モデル

認証文脈を含む経路は、明示宣言がない限りキャッシュ不可を既定値にします。

4. 回帰ドリル

プロキシイメージ更新時にスマグリング回帰テストを必須化し、失敗をリリースブロッカーにします。

組織面の落とし穴

この種のインシデントでは責任が分散しがちです。プラットフォーム、セキュリティ、サービス開発が別々に最適化すると、全体の解釈一貫性が誰のKPIにも入りません。そこで、「リクエスト解釈一貫性」責任者を明示し、横断で意思決定できる体制にするのが効果的です。

30日改善チェックリスト

環境別にIngressハードニング基準を標準化
パーサー不一致をSLO化
ファズ検体をCIゲートへ統合
バックエンド実装向け厳格パース指針を公開
キャッシュ汚染/セッション混線の机上演習を実施

CVE対応のゴールは「修正版を当てた」ではありません。敵対的入力でもIngressとバックエンドが同じ境界を解釈し続けることを証明できて、初めて運用品質が上がったと言えます。