Критична уязвимост в ASP.NET Core и как да защитите приложенията си

В последните времена, ASP.NET Core е разтърсен от няколко критични пропуска в сигурността. които пряко засягат удостоверяването, защитата на данните и самия уеб сървър Kestrel. Ако разработвате или поддържате приложения на .NET, това не е просто технически детайл: говорим за уязвимости с много високи CVSS резултати (9,1 и дори 9,9), способни да отворят вратата за ескалация на привилегиите, представяне за друг потребител и разкриване на силно чувствителна информация.

Отвъд шума от бюлетините за сигурност, ключово е да се разбере Какво точно не работи в ASP.NET Core и кои пакети и версии са засегнати?и как трябва да реагира един съвременен екип за разработка, работещ с най-добрите практики за CI/CD и DevSecOps, например IDE и ключови инструменти за тестване на приложенияЩе разгледаме най-сериозните случаи (включително CVE-2026-40372 и CVE-2025-55315), ще прегледаме Препоръчани от Microsoft мерки за смекчаване И докато сме на темата, нека разгледаме модела за обработка на грешки и изключения в ASP.NET Core, защото пробив в сигурността без добра наблюдаемост е като търсене на игла в купа сено.

Критична уязвимост в DataProtection: CVE-2026-40372

Един от най-сериозните инциденти, които са засегнали екосистемата, е CVE-2026-40372, критична уязвимост в Microsoft.AspNetCore.DataProtection, закърпен от Microsoft с актуализация извън цикъла във версия .NET 10.0.7. Сериозността не е незначителна: CVSS 3.1 от 9,1 (Преглед) и отдалечена експлоатация без удостоверяване.

Тази уязвимост засяга Версии 10.0.0 до 10.0.6 на пакета Microsoft.AspNetCore.DataProtection NuGet и свързани зависимости, като например Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Проблемът се крие в много фин, но опустошителен недостатък в криптографската логика на управлявания удостоверен шифър на ASP.NET Core.

Уязвимият компонент изчислява тага за валидиране на HMAC на базата на неправилните байтове в полезния товар А в определени случаи дори изхвърля генерирания хеш. Тази погрешна валидация напълно нарушава очаквания модел на доверие: атакуващият може да конструира полезни товари, които изглеждат легитимни, заобикаляйки проверките за автентичност на системата за защита на данните.

Практическите последици са особено сериозни.Това е така, защото DataProtection не се използва само за криптиране на произволни данни; той е в основата на много механизми за сигурност на ASP.NET Core: бисквитки за удостоверяване, токени против фалшифициране, TempData, OIDC състояние и други елементи, които разчитат на този ключов звено. Ако тези обекти могат да бъдат фалшифицирани или декриптирани, нападателят има много директен път към ескалация на привилегиите.

Реално въздействие: бисквитки, токени и компрометирана самоличност

Пропускът в DataProtection позволява на нападателя фалшифициране на полезни товари, които преминават криптографски проверки и дори в някои сценарии декриптиране на предварително защитени данниВ среди, където се използват ASP.NET Core Protection API, това се превръща в много обезпокоителен набор от атаки.

Потенциално изложените данни включват бисквитки за удостоверяване, токени против фалшифициране, временни данни, OIDC статус и други вътрешни токениВ най-лошия случай, неудостоверен нападател може да създаде „бисквитка“ или токен, който го идентифицира като потребител с повишени привилегии, като например администратор на приложение или администратор на вътрешна услуга.

Сценарият се утежнява, защото ако по време на уязвимия прозорец нападателят успее получавате високо ниво на достъп, това може да накара приложението да издаде легитимни, но злонамерено получени активи: API ключове, токени за обновяване на сесия, връзки за нулиране на парола или постоянни ключове за достъпВсички тези артефакти ще останат валидни дори след надграждане до .NET 10.0.7, освен ако не бъдат взети допълнителни мерки.

С други думи, дори и да поставите пластира, ако не реагирате правилно, Вашата система все още може да бъде изложена на токени, вече издадени при компрометирани условия.Ето защо Microsoft сравнява този недостатък с исторически уязвимости като MS10-070, свързани с проблеми с padding-oracle в наследено ASP.NET криптиране.

Microsoft откри тази регресия в резултат на Доклади от клиенти, които са имали проблеми с дешифрирането след инсталиране на .NET 10.0.6 по време на априлския Patch Tuesday. След разследване на инцидента (първоначално документиран в aspnetcore issue #66335), екипът откри, че това не е просто функционална грешка, а значителна дупка в сигурността, изискваща спешна пач извън цикъла.

Работни условия и засегнати среди

Въпреки че провалът е критичен, Не всички среди са изложени по подразбиране.Според официална информация, за да се използва CVE-2026-40372, трябва да бъдат изпълнени няколко специфични условия, свързани с пакетите и средата за изпълнение.

От една страна, приложението трябва да използва уязвимите версии на пакета Microsoft.AspNetCore.DataProtection (10.0.0 до 10.0.6) или библиотеки, които го зареждат по време на изпълнение. Освен това, уязвимостта има по-голямо въздействие върху операционни системи, различни от Windows, като например Linux и macOSТова се вписва идеално в типичното внедряване на ASP.NET Core в контейнери, оркестратори и облачни платформи.

Векторът на атака обикновено се изпълнява през мрежата, без необходимост от предварително удостоверяванеТова увеличава опасността му в приложения, изложени на интернет. Нападателят може да изпраща специално създадени полезни товари, сякаш са просто още един клиент на системата, без да изисква валидни идентификационни данни.

На практика това означава, че инфраструктури, базирани на микросървиси, Docker контейнери и PaaS платформи Системите, които разчитат на DataProtection за споделяне на ключове или състояние на удостоверяване между инстанции, са цели с висок приоритет. Ако ключодържателят не е бил актуализиран и ротиран, съществува реален риск еднократно компрометиране да ескалира до постоянен и труден за откриване достъп.

Поради всички горепосочени причини, екипите за сигурност на приложенията трябва Анализирайте подробно кои услуги зареждат уязвимия пакет и на кои операционни системи работят, вместо да се приема, че проблемът засяга само много специфични сценарии.

Спешни действия: надграждане до .NET 10.0.7 и ротация на ключове

Основната препоръка на Microsoft е ясна: Незабавно актуализирайте пакета Microsoft.AspNetCore.DataProtection до версия 10.0.7 и прекомпилирайте приложенията с коригираните среди за изпълнение и SDK (например, .NET SDK 10.0.203 и свързаните с него среди за изпълнение).

За да потвърдите, че средата е правилно актуализирана, трябва да изпълните dotnet –info и проверете дали версията на средата за изпълнение е 10.0.7 съответно. Не е достатъчно да инсталирате средата за изпълнение на сървъра; от съществено значение е възстановяване и повторно внедряване на приложения използване на актуализирани изображения или пакети на контейнери, за да се гарантира, че производственият код е свързан с коригираните двоични файлове.

Както обаче бе споменато по-рано, прилагането на корекцията само по себе си няма да поправи вече възникнали щети. Microsoft силно препоръчва да не се прави това. завъртете ключодържателя DataProtection в среди, които са били изложени на риск, за да се обезсилят всички токени, бисквитки или идентификационни данни, генерирани злонамерено по време на периода на уязвимост.

В допълнение към актуализирането и ротацията на ключовете, е разумно принудително затваряне на активни сесии (анулиране на „бисквитки“ за вход, токени за достъп и др.), изискват повторно удостоверяване и активират подробен одит на лог файловете да преглежда подозрителни дейности, особено нетипичен административен достъп, създаване на API ключове, нулиране на пароли и привилегировани операции.

От гледна точка на DevSecOps, този инцидент подчертава важността на включването скенери за зависимости във веригата CI/CD и за активиране на автоматични предупреждения, когато се появят критични уязвимости в пакети на трети страни. При DataProtection, както при всяка криптографска библиотека, малка промяна в поведението може да наруши целия модел на сигурност, ако не е стриктно валидирана.

Друга критична уязвимост: подправяне на HTTP заявки в Kestrel (CVE-2025-55315)

В допълнение към уязвимостта в DataProtection, е съобщена и друга... изключително сериозен пропуск в сигурността в ASP.NET CoreТози път фокусът беше върху уеб сървъра Kestrel. Идентифициран като CVE-2025 55315-Класифицирана е като грешка при подправяне на HTTP заявка с оценка на тежестта 9,9 от 10.

Същността на проблема е, че Атакуващ може да инжектира втора злонамерена HTTP заявка в привидно легитимна заявка.Това е типично за така наречените атаки за контрабанда на заявки или манипулация на HTTP рамки. Тази техника може да се използва за заобикаляне на контролите за сигурност, разположени на прокси сървъри, балансьори на натоварването или самия сървър, и да накара бекенда да обработва данни, които никога не е трябвало да приема.

Според предупреждението на Microsoft, потенциалното въздействие включва достъп до чувствителна информация, кражба на идентификационни данни, неоторизирана промяна на файлове и дори възможността за причиняване на сървърни повреди, които влияят на достъпността. Чрез директно въздействие върху транспортния слой на HTTP, обхватът на атаките е много широк, от заобикаляне на удостоверяването до пренасочване на трафика към вътрешни маршрути.

Уязвимостта засяга по-специално Microsoft.AspNetCore.Server.Kestrel.Core Тази уязвимост съществува в определени версии на ASP.NET Core и се счита за един от най-сериозните проблеми със сигурността, с които платформата се е сблъсквала през последните години. Отново, тя е експлоатиран вектор за неавтентични нападатели, което значително увеличава повърхността за атака.

Бари Доранс, технически ръководител по сигурността в .NET, обясни, че Такъв висок резултат отразява най-лошия възможен сценарий.Тъй като действителното въздействие зависи до голяма степен от това как е изградено всяко приложение, оценката се основава на предпоставката за заобикаляне на механизмите за сигурност с промени в обхвата, което е видът отказ, считан за неприемлив в корпоративна среда.

Засегнати версии и корекции за Kestrel и ASP.NET Core

За да се справи с CVE-2025-55315, Microsoft пусна Актуализации на сигурността, специфични за различни клонове на .NET и ASP.NET Core, обхващаща както по-стари, така и по-нови версии, включително ASP.NET Core 2.3, 8.0 и 9.0.

В среди, където се използва .NET 8 или по-нова версияПрепоръчителното смекчаване включва прилагане на всички налични корекции чрез Microsoft Update и впоследствие да проверите дали средата за изпълнение и пакетите са в коригираната версия. Особено важно е да се провери дали приложенията са прекомпилирани с тези версии и дали производствените образи вече не съдържат уязвими двоични файлове.

В случай на проекти, които все още се изпълняват .NET 2.3Microsoft посочва, че е от съществено значение Актуализирайте препратката към пакета Microsoft.AspNet.Server.Kestrel.Core до версия 2.3.6Прекомпилирайте решението и разгръщайте отново внедряванията. В противен случай Kestrel ще продължи да обработва заявки с неправилната логика, която позволява подправяне на HTTP заявки.

Разгръщанията, които използват самостоятелни приложения или приложения, пакетирани като един файл Те също така имат задължението да компилират от нулата с обновените версии на средата за изпълнение, в противен случай изпълнимият файл все още ще съдържа уязвимия код. Лесно е да забравите тази подробност, ако разчитате твърде много само на актуализиране на хоста.

Заедно с актуализациите на самата рамка, Microsoft пусна Пачове за Microsoft.AspNetCore.Server.Kestrel.Core и други свързани компонентиТова има за цел да засили стабилността на парсинга и обработката на HTTP заявки. Накратко, това не е единична, изолирана корекция, а по-скоро координирано подобрение в няколко точки от ASP.NET Core стека.

Допълнителни критични актуализации в ASP.NET Core и глобален риск

Освен тези специфични случаи, Microsoft пуска критични корекции за други уязвимости в ASP.NET Core Тези уязвимости могат да доведат до отдалечено изпълнение на код (RCE), ескалация на привилегиите и атаки от типа „отказ от услуга“ (DoS). Комбинацията от тези недостатъци ясно показва, че рамката, колкото и зряла да е, не е имунизирана срещу опасни регресии.

Тези неуспехи засягат Ключови компоненти на средата за изпълнение на ASP.NET CoreТова включва обработка на HTTP заявки, мидълуер за удостоверяване и оторизация, както и API, свързани със сериализация и десериализация на данни. В много случаи нападателите могат да експлоатират... деформирани входни данни или манипулирани полезни товари да предизвика неочаквано поведение.

Засегнатите версии обикновено съответстват на издания преди публикуването на корекции за сигурност през април 2026 г.Следователно, одитът на версиите е задължителен във всички производствени среди, които продължават да работят с по-стари компилации. Оставянето на сървърите остарели в днешно време е рецепта за бедствие.

От бизнес гледна точка, невнедряването на тези корекции може да има много сериозни последици: загуба на поверителност на данните, компрометирана цялост, недостъпност на основни услуги и репутационно въздействие, от което отнема години, за да се възстанови. Организациите, които разчитат на ASP.NET Core за критично важни приложения, трябва да гледат на управлението на корекциите като на непрекъснат процес, а не като еднократна задача.

Общата препоръка на Microsoft е да Приложете корекции веднага щом станат налични и прегледайте настройките за сигурност на среди.Засилете наблюдението на подозрителна активност и прегледайте сигурните процеси на разработка, за да сведете до минимум вероятността от въвеждане на уязвимости в самия код на приложението.

Обработка на грешки и изключения в ASP.NET Core: ключово парче от пъзела

Когато говорим за сигурност, често се сещаме само за пачове и криптография, но... Добрата система за обработка на грешки в ASP.NET Core е от съществено значение. за откриване, разследване и смекчаване на инциденти. Рамката предлага множество механизми за обработка на изключения, връщане на подходящи кодове за състояние и предоставяне на стандартни отговори, като например ProblemDetails, в API.

В среди за разработка, ASP.NET Core по подразбиране позволява Страница за изключения за разработчици когато са изпълнени определени условия (обикновено в среда за разработка). Тази страница се задейства от мидълуера DeveloperExceptionPageMiddleware, който се поставя в началото на HTTP конвейера, за да прехващане на необработени изключения, както синхронни, така и асинхроннии да показвате подробна информация.

Страницата с изключения за разработчици може да включва стекови трасирания, параметри на низове на заявки, бисквитки, HTTP заглавки и метаданни на крайни точкиТова е великолепен инструмент по време на разработка, но логично, Не трябва да е активирано в продукцията.защото разкриването на вътрешни детайли улеснява живота на нападателите.

В производствена среда препоръчителната практика е да конфигурирате персонализирана страница за грешки, използваща UseExceptionHandlerТози мидълуер улавя необработени изключения, регистрира ги и изпълнява заявката отново през алтернативен канал, обикновено сочейки към маршрут като /Error.

При повторно инсталиране на тръбите е важно да се има предвид, че Мидълуерите могат да бъдат извикани отново със същия HttpContext.Следователно е препоръчително да се почистят вътрешните състояния, да се кешират резултатите или да се използват повторно вече прочетени данни (например тялото на заявката), за да се избегне причиняването на допълнителни грешки. Освен това, обхватът на услугите остава същият по време на повторното изпълнение.

Достъп до изключения и централизиран контрол с IExceptionHandler

За да получи подробна информация за изключението, което е задействало страницата за грешка, ASP.NET Core предоставя функцията Функция за път на обработчика на изключения (IExceptionHandlerPathFeature)Чрез HttpContext.Features.Get Както оригиналният път на заявката, така и самият обект Exception могат да бъдат извлечени.

Често срещан модел в Razor Pages се състои от Съхранявайте RequestId и лесно удобен код за грешка в модела на страницатаИзползването на IExceptionHandlerPathFeature ви позволява да персонализирате съобщението въз основа на типа изключение (например FileNotFoundException) или пътя, който е причинил неуспеха. Това ви позволява да показвате по-полезни грешки на потребителя, без да филтрирате вътрешни подробности.

В допълнение към подхода, базиран на страници или специфичен за контролер, ASP.NET Core предлага интерфейса Обработчик на изключения (IExceptionHandler) като централизиран механизъм за обработка на изключения. Реализациите на този интерфейс са регистрирани с AddExceptionHandler и те се изпълняват по ред, като връщат true, когато са обработили изключението, и false, когато предпочитат да делегират поведението по подразбиране.

Тази система улеснява например записване на грешки във външна система, прилагане на условна логика според вида на изключението. или да променяте глобалния HTTP отговор, без да е необходимо да докосвате всеки контролер поотделно. Започвайки с .NET 10, мидълуерът за изключения ви позволява също да конфигурирате SuppressDiagnosticsCallback, за да решите кога да потиснете показателите и регистрационните файлове в случай на вече обработени изключения.

Друг много гъвкав вариант е да използвате ламбда в UseExceptionHandlerТова включва директен достъп до контекста, задаване на код на състоянието и тип съдържание (Content-Type) и ръчно писане на отговора. Можете дори да използвате IProblemDetailsService в рамките на тази ламбда функция, за да издадете стандартен отговор ProblemDetails, който ясно описва проблема.

Страници с код на състоянието и отговори на ProblemDetails

По подразбиране, ASP.NET Core приложение Не показва страници, които са съвместими с HTTP кодове за състояние, като например 404.Той просто връща кода и празно тяло. За да обогатите това преживяване и да улесните отстраняването на грешки, можете да активирате мидълуера за страницата със състоянието, като използвате UseStatusCodePages.

UseStatusCodePages поддържа няколко режима: Обикновен текст с общо съобщение, ламбда изрази за пълно персонализиране на отговора или варианти, които пренасочват или изпълняват повторно конвейера към алтернативна крайна точка, като например UseStatusCodePagesWithRedirects и UseStatusCodePagesWithReExecute.

С UseStatusCodePagesWithRedirects, междинният софтуер Издава грешка „302 Found“ и пренасочва клиента към URL адрес, който обикновено предоставя по-удобен за потребителя изглед., обикновено връщайки 200 OK. Този подход има смисъл, когато искате адресната лента да отразява крайния път на грешката и не искате да запазите оригиналния код на състоянието.

UseStatusCodePagesWithReExecute, от друга страна, Първоначалният код на състоянието не се променяВместо това, той изпълнява заявката отново по различен маршрут, за да генерира тялото на отговора. Оригиналният URL адрес се запазва в адресната лента на браузъра и точката на грешка може да извлече оригиналния маршрут и заявка чрез IStatusCodeReExecuteFeature, което е много полезно за регистриране и отстраняване на грешки.

В сферата на API, ASP.NET Core е възприел стандарта ProblemDetails като стандартен формат за отговори на грешкиЧрез регистриране на AddProblemDetails в контейнера на услугата, мидълуерът може автоматично да генерира JSON отговори с полета като тип, заглавие, статус и traceId, когато възникнат грешки на клиента или сървъра без тяло.

Това поведение може да бъде персонализирано от Опции за подробности за проблема. Персонализиране на подробности за проблемаТова включва добавяне на разширения, като например идентификатор на възел (напр. име на машина) или други метаданни, които помагат за проследяване на проблеми в разпределени среди. Възможно е също така да се имплементира персонализиран IProblemDetailsWriter, който решава кои състояния да обработва и как да сериализира детайлите.

Уроци за DevSecOps и най-добри практики за непрекъснато внедряване

Каскадата от уязвимости в ASP.NET Core и неговата .NET екосистема представя няколко ключови урока за всеки сериозен екип за разработка: Зависимостите от трети страни са критичен вектор; лошо внедрената криптография нарушава целия модел на доверие. и механизмите за удостоверяване са се превърнали в основна цел за нападателите.

От гледна точка на DevSecOps, това става от съществено значение интегриране на анализ на зависимостите В CI/CD конвейерите, провеждайте непрекъснати тестове за сигурност и поддържайте ясна видимост на всички компоненти на трети страни, които се включват в проекта. Инструментите за анализ на състава на софтуера (SCA) и скенерите за уязвимости вече не трябва да бъдат опционални, а да станат част от стандартния работен процес за интеграция.

Също така е важно да се подсили Одити на логове и наблюдение на събития за сигурностТова е особено вярно по отношение на удостоверяването, издаването на токени, създаването на сесии, промените в разрешенията и административните операции. Без добро регистриране и предупреждения, уязвимост като CVE-2026-40372 или CVE-2025-55315 може да бъде незабелязано експлоатирана в продължение на месеци.

Въпреки сложността си и обема на скорошните грешки, ASP.NET Core остава стабилна рамка, стига да е правилно актуализирана и сигурно конфигурирана. Комбинацията от бързо инсталиране на корекции, ротация на ключове, когато е необходимо, добри практики за обработка на грешки и проактивен подход към сигурността Това прави разликата между стабилна платформа и лесна мишена за нападателите.

Целият този набор от уязвимости и механизми за смекчаване ни напомня, че Сигурността в ASP.NET Core не е просто въпрос на прилагане на случайни корекции.а по-скоро да се приеме непрекъсната дисциплина: наблюдение на версиите на пакетите и средата на изпълнение, грижа за обработката на грешки и изключения, преглед на HTTP отговорите и ProblemDetails, които излагаме, и поддръжка на всичко това със зрели DevSecOps процеси, които ни позволяват да реагираме бързо, когато се появи нов критичен отказ в .NET екосистемата.