HTTP/1.1 非同期攻撃に対する Fastly のレジリエンス

2025年8月6日、Fastly はセキュリティ状況に関する最新情報を発表し、今週の Black Hat で James Kettle 氏により公開された HTTP/1.1のリクエストスマグリング攻撃に対して当社が耐性を持つことを確認しました。同氏の包括的な分析『HTTP/1.1 Must Die: The Desync Endgame』では、新しい種類の攻撃手法が明らかにされており、主要な CDN インフラストラクチャに存在する重大な脆弱性を通じて、数千万もの Webサイトが危険にさらされていることが示されています。

これらの新たな攻撃手法は、HTTP/1.1の「致命的な欠陥」である、リクエスト境界の脆弱さと複数の長さ指定方法を利用し、極端なあいまいさを生み出します。攻撃者はこれを悪用して、サイトの乗っ取り、認証情報の盗難、キャッシュポイズニングを引き起こすことが可能となります。

これらの調査結果の重大性を考慮すると、当然の疑問が生じます。Fastly は影響を受けているのでしょうか？

Fastly のプラットフォームは、セキュリティ研究者によって発見された新旧の HTTP/1.1リクエストスマグリング攻撃手法に対して脆弱性が存在しないことを確認しております。

Fastly の Edge Cloud Platform は、毎日1.8兆件の HTTP リクエストを処理します*。他の CDN やプラットフォームでは顧客のサイトやサービスに影響する重大な脆弱性が見つかりましたが、Fastly のアーキテクチャはこうした攻撃を防ぎ、HTTP リクエストスマグリングに対して長年積み重ねてきた耐性の実績を引き続き示しています。Fastly の統合型ネットワークスタックは、リクエスト処理の一貫性を実現し、このような攻撃から顧客を保護します。プロトコルとそのインタラクションは年々複雑化していますが、Fastly がアーキテクチャレベルで積極的に取り組んできたセキュリティ施策は、業界全体が毎年新たな攻撃への対応に追われる中で、先見性を持っていたことを証明しています。

HTTP/1.1 リクエストスマグリング攻撃に対する Fastly のレジリエンス

HTTP 非同期化攻撃（HTTP リクエストスマグリング攻撃とも呼ばれます）の根本的な原因は、パーサーの不一致にあります。これは、異なるシステムが HTTP リクエストを解釈する方法に、それぞれの解析ロジックの差異による不一致が生じることに起因します。Fastlyは、スタック全体で単一の解析を採用するアーキテクチャの統一性によりこれを解消し、動作の不一致や脆弱性を生むエッジケースが発生する余地が生じないようにします。

従来の CDN アーキテクチャでは、パーサーの違いが連鎖的に発生し、変換のたびに脆弱性（Black Hat で公開されたものなど）が生じるリスクがありました。競合他社が単に脆弱性を「修正」しただけで新たな亜種に直面する中、Fastlyの防御的実装は持続的な保護を提供します（図1）。多くの競合他社がそうした脆弱性に対して場当たり的に「パッチ」を適用してきたのに対し、Fastly の防御設計は長期的な保護を提供します（図1）。

私たちは、一時的な対策が顧客に不当な負担を強いるものであり、ベンダー側の脆弱性に対する保護策を自ら調達せざるを得ない状況を生むと根本的に考えています。その代わりに、Fastlyは保護機能をアーキテクチャに組み込みました。設計段階から安全性を考慮した「セキュア・バイ・デザイン」を採用しているため、セキュリティは後付けの対策ではなく、基盤そのものとなっています。  

関連する攻撃の歴史

当社はプロトコル仕様のセキュリティ要件を上回る対策を行うことで保護を提供してきました。ここでは、PortSwigger Research の講演やブログで紹介された関連攻撃を振り返ります。

• 2019年: 他社が被害を受けた元々の CL.TE/TE.CL 攻撃に耐性を持つ

• 2021年: 競合他社がパッチ適用に奔走する中、H2.CL/H2.TE から保護

• 2022年: 必須の検証により CL.0攻撃の影響を受けない

• 2024年: TE.0やファンキー・チャンクの脆弱性に対して耐性を持つ

• 2025年: Expect ベースおよび0.CL 攻撃に対する耐性を確認（他社では報奨金35万ドル以上が出る脆弱性）

他社では「互換性の懸念」からロードバランサーへのパッチ適用が進まず、nginx には有効な0.CL 対策がないのに対して、Fastly は厳格な基準の適用により攻撃の全クラスを排除しています。

大量の顧客トラフィックに対応するための安全な HTTP 処理の基準を引き上げる

Fastly の HTTP 処理パイプラインは、統合されたコンポーネントを通じて多重防御を実現しています。

• エッジでのリクエスト検証 : 曖昧なHTTP/1.1リクエストは処理開始前に即時拒否します。

• 統一された HTTP パース : すべてのコンポーネントで1つのパーサーを使用することで、不整合を低減します。

• 厳格な正規化 : リクエストをクリーンアップ・再構築してから転送します。

• コントロールされたプロトコル変換 : HTTP/2および HTTP/3から HTTP/1.1へのダウングレードを、一貫した安全な方法で処理します。

これは、他の CDN が採用している混在型のプロキシチェーンとは対照的です。他の CDN では、HTTP バージョンの一貫性のない処理によって、数百万の Webサイトに深刻な脆弱性が生じていました。

私たちは、Internet Engineering Task Force (IETF) の標準が、顧客トラフィックの保護に関しては最低基準であり、上限ではないと考えています。当社のリクエスト検証は RFC 要件に厳密に従っており、特に今回のような攻撃を防ぐのに役立ちます。

他の CDN が不正な形式のヘッダーに関連する問題に対して35万ドル以上のバグ報奨金を支払っていたのに対し、Fastly は不正な形式の Expect ヘッダーを完全に拒否するなど、厳格な検証により、これらの攻撃を完全に阻止しました。

Fastly のアーキテクチャは、重要なセキュリティの前提をエンドツーエンドで維持し、0.CL や二重非同期化攻撃などの高度な非同期化攻撃から保護します。たとえば、競合他社の CDN で発生した、広範囲にわたるレスポンスの乗っ取りを可能にした脆弱性は、Fastly のアーキテクチャに対しては効果がなかったでしょう。

まとめ : Fastly の永続的なセキュリティ

PortSwigger Research が実証しているように、セキュリティコミュニティは、重要なインターネットインフラストラクチャの欠陥の特定に絶え間なく熱心に取り組んでいます。今週の Black Hat の発表は、重要な脆弱性を発見するための長い一連の取り組みの中で最新のものです。プロトコルとサービスの根本的な欠陥により、何百万もの Webサイトが定期的に危険にさらされる可能性があります。Fastly は今後も、アーキテクチャ上の保護策を最優先に掲げ、顧客のためにこの責任を果たしていきます。

Fastly は進化する脅威をモニタリングし、防御策を適応させることで、顧客に最高レベルのセキュリティを提供し続けています。お客様の Webアプリケーションは、弊社のプロアクティブなアプローチとアーキテクチャのレジリエンスによって保護されます。

次回のブログでは、増大する非同期化攻撃の脅威、HTTP/1.1の課題、Fastly 独自のレジリエンスについてさらに詳しく掘り下げていきます。Fastly が進化する脅威からアプリケーションを保護する方法について詳しく知りたい場合は、今すぐ当社の専門家にお問い合わせください。

* 2023年7月31日現在