Kestrelウェブサーバーの欠陥によりリクエストスマグリング攻撃が可能に。ただし、実際のリスクはアプリケーションコードとデプロイ方法に依存。
Microsoftは、ASP.NET Coreの重大な脆弱性に対処するパッチを公開しました。この脆弱性はCVSS深刻度スコア9.9を獲得し、同社がウェブ開発フレームワークの欠陥に対してこれまでに付与した中で最も高い評価となりました。
この脆弱性はCVE-2025-55315として追跡されており、ASP.NET Coreに組み込まれているKestrelウェブサーバーコンポーネントに影響します。認証済みの攻撃者がHTTPリクエストスマグリングを利用してセキュリティ機能を回避できる可能性があると、同社はセキュリティアドバイザリで述べています。
「ASP.NET CoreにおけるHTTPリクエストの不一致な解釈（『HTTPリクエスト/レスポンススマグリング』）により、認証済みの攻撃者がネットワーク越しにセキュリティ機能を回避できる」とアドバイザリには記載されています。
この欠陥は、現在サポートされているすべてのASP.NET Coreバージョン（バージョン8、9、10）およびWindows専用の.NET Framework上で動作する旧バージョンのASP.NET Core 2.3にも影響します。
攻撃者に何ができるか
この脆弱性はリクエストスマグリング攻撃に関連しています。これは、ウェブサーバーやアプリケーションがHTTPリクエストをどのように解釈するかを悪用するものです。攻撃者は、正規の最初のリクエストに見せかけて悪意のある2つ目のリクエストを隠すことができ、これにより本来認証が必要な操作を認証なしで実行できる可能性があるとアドバイザリは付け加えています。
MicrosoftのASP.NET CoreセキュリティプログラムマネージャーであるBarry Dorrans氏は、GitHubのアドバイザリで、スマグリングされたリクエストがさまざまな悪意ある行動を実行できると述べています。
「攻撃者はこの脆弱性を利用して、別のユーザーとしてログインしたり、クロスサイトリクエストフォージェリーチェックを回避したり、インジェクション攻撃を実行したりできる」と彼は記しています。
しかし、Dorrans氏は実際のリスクはアプリケーションの記述方法やデプロイ方法に大きく依存すると強調しています。「アプリケーションコードが何らかのおかしなことをしていて、各リクエストで本来行うべきチェックを多数省略していない限り、悪い結果になる可能性は低い」と述べています。
CVSSスコアに関する混乱
Dorrans氏が実際のリスクについて慎重な評価を示しているにもかかわらず、9.9というCVSSスコアは開発者の間で大きな混乱を招いており、多くの人が本当にそれほど極端な深刻度なのか疑問を呈しています。
Dorrans氏はこの点についてGitHubのディスカッションで直接説明し、Microsoftのスコアリング手法は最悪のシナリオを考慮していると述べています。
「ASP.NET Core単体で見れば、このスコアは『そこまで高くはならない』」と彼は書いています。しかし、Microsoftは「スコープが変わるセキュリティ機能のバイパス」の可能性に基づいて脆弱性を評価しており、攻撃が最初に脆弱だったコンポーネント以外にも影響を及ぼす可能性があるためです。
開発者からどのようなアプリケーションコードパターンが脆弱になりうるか尋ねられると、Dorrans氏は慎重な回答を示しました。
「リクエストに何らかの処理を行うものはすべて問題になる可能性がある」と彼は述べ、「認証を行い、認証に基づいてアクセスルールを設けているアプリも脆弱になりうる」と付け加えました。
ただし、これらはあくまで個人的な見解であり、Microsoftの公式なガイダンスではないと彼は述べています。
誰がパッチを適用する必要があるか？
この脆弱性は幅広いASP.NET Coreバージョンに影響します。アドバイザリによると、ASP.NET Core 10.0.0-rc.1.25451.107以前、ASP.NET Core 9.0.9以前、ASP.NET Core 8.0.20以前、またはMicrosoft.AspNetCore.Server.Kestrel.Coreバージョン2.3.0以前のASP.NET Core 2.xを実行しているアプリケーションは、すべてこの欠陥の影響を受けます。
組織によって、デプロイモデルに応じて異なるパッチ適用要件があります。フレームワーク依存デプロイメントを利用しているアプリケーションは、サーバーにインストールされた.NETランタイムに依存しているため、管理者がサーバー自体を更新する必要があります。ランタイムをアプリケーションと一緒にバンドルするセルフコンテインドデプロイメントを使用している場合は、影響を受ける各アプリケーションを個別に再ビルドし、再デプロイする必要があります。
Microsoftは、すべてのサポート対象リリースに対して修正版を公開しました。開発者は、バージョン8の場合は.NET 8.0.21 Runtimeまたは.NET 8.0.318 SDK、バージョン9の場合は.NET 9.0.10 Runtimeまたは.NET 9.0.111 SDK、バージョン10のプレリリースの場合は.NET 10.0.0-rc.2.25476.107 Runtimeにアップグレードする必要があるとアドバイザリは述べています。レガシーなASP.NET Core 2.xアプリケーション向けには、MicrosoftはNuGet経由でKestrel.Coreパッケージのバージョン2.3.6をリリースしました。
すでに保護されている場合もある
ただし、すべての組織が直ちに対応する必要があるわけではありません。Dorrans氏によれば、リバースプロキシやAPIゲートウェイで保護されているアプリケーションは、すでに十分な防御策が講じられている場合があります。
「ゲートウェイやプロキシがスマグリングされたリクエストを除去する場合、アプリケーションは保護されています」と彼は記しています。しかし、そのような中間フィルタリングなしでインターネットに直接公開されているKestrel実装は依然として脆弱です。
Microsoftは公式アップデートガイドで、この脆弱性が現時点で実際に悪用されている事例は確認されていないと述べています。
それにもかかわらず、Dorrans氏は組織ごとに自社のリスクを慎重に評価するよう助言しています。「アプリケーションのリスクを評価できるのはあなただけです」と彼は記し、「慎重を期すなら、できるだけ早くパッチを適用するのが望ましい」と推奨しています。
