Microsoft выпустила исправления для критической уязвимости в веб-сервере Kestrel (ASP.NET Core), получившей идентификатор CVE-2025-55315 и оценку 9,9 из 10 по CVSS. Речь идет об атаке класса HTTP request smuggling, которая при определенных условиях позволяет протащить дополнительный запрос «за спиной» фронтенд-прокси или веб-сервера, что открывает путь к краже учетных данных, обходу механизмов безопасности и другим злоупотреблениям.
Что известно об уязвимости CVE-2025-55315 в Kestrel
Уязвимость затрагивает Kestrel — высокопроизводительный веб-сервер, используемый ASP.NET Core. По данным Microsoft, аутентифицированный атакующий мог внедрить дополнительный HTTP-запрос, чтобы перехватить чувствительные данные (включая учетные записи других пользователей), модифицировать содержимое файлов на целевом сервере и потенциально вызвать сбой сервиса. Высокая оценка CVSS отражает совокупность влияния на конфиденциальность, целостность и доступность.
Кому обновляться: доступные патчи и пакеты
Для устранения риска Microsoft выпустила обновления для Microsoft Visual Studio 2022, ASP.NET Core 2.3, ASP.NET Core 8.0 и ASP.NET Core 9.0, а также пакет Microsoft.AspNetCore.Server.Kestrel.Core для приложений на ASP.NET Core 2.x. Рекомендуется обновить целевые фреймворки и серверные пакеты, выполнить пересборку и повторное развертывание рабочих нагрузок. В средах с контейнерами важно пересобрать образы и синхронизировать базовые слои с репозиториями поставщиков.
Как работает HTTP request smuggling и почему это опасно
Атаки типа request smuggling эксплуатируют расхождения в разборе HTTP-запросов между различными компонентами цепочки — например, между балансировщиком/прокси и бэкендом. Наиболее известный сценарий — несовпадение трактовки заголовков Content-Length и Transfer-Encoding. В результате злоумышленник «прячет» дополнительный запрос, который обрабатывается как часть следующего легитимного обмена, что создает возможности для перехвата сессий, обхода CSRF-защиты, внутренних запросов (SSRF) и вредоносных инжектов.
Зависимость риска от логики приложения
В Microsoft подчеркивают, что конечный эффект сильно варьируется от реализации. Как отмечает менеджер программы безопасности .NET Барри Дорранс, «мы оцениваем уязвимость по худшему сценарию: обход защиты с изменением области воздействия. Насколько это вероятно? Вряд ли, если только в коде вашего приложения нет странностей и он не пропускает проверки, которые должны выполняться на каждом запросе. В любом случае, пожалуйста, обновитесь». На практике это означает, что даже при низкой вероятности успешной эксплуатации в конкретном сервисе риск акумулируется через инфраструктурные особенности — цепочки прокси, кэширование, многоарендные среды и API-шлюзы.
Практические рекомендации по снижению риска
Обновления и инвентаризация
Немедленно примените патчи ко всем экземплярам ASP.NET Core и Kestrel. Проведите инвентаризацию сервисов, где используется HTTP/1.1 и проксирование (Nginx, Apache, обратные прокси в облаках), чтобы удостовериться, что фронтенд и бэкенд обновлены согласованно.
Безопасная конфигурация цепочки доставки
Проверьте нормализацию и фильтрацию заголовков на уровне прокси и бэкенда, запретите неоднозначные комбинации Content-Length/Transfer-Encoding, синхронизируйте таймауты keep-alive и размер буферов. По возможности ограничьте HTTP-пайплайнинг и проверьте правила WAF, ориентированные на HRS-паттерны.
Тестирование и мониторинг
Включите проверки на HTTP request smuggling в пайплайны безопасности (DAST/SAST), используйте регулярное тестирование с профилями для CL/TE-несоответствий. Усильте журналирование на уровне прокси и приложения: корреляция запросов, аномальные последовательности, неожиданные 4xx/5xx «рядом» с авторизацией. Перепроверьте CSRF-мидлвары и параметры валидации на уровне контроллеров.
Критическая оценка CVSS 9.9 и характер уязвимости в Kestrel делают обновление приоритетом для команд, поддерживающих ASP.NET Core. Даже если вероятность эксплуатации в вашем приложении кажется низкой, сочетание прокси, кэшей и сложной логики аутентификации увеличивает площадь атаки. Обновите стек, пересмотрите конфигурацию HTTP-цепочки и включите проверку HRS в процедуры тестирования безопасности — это позволит снизить риск компрометации учетных данных и обхода защитных механизмов.
