Vulnerabilitate critică în ASP.NET Core și cum să vă protejați aplicațiile

În ultimele vremuri, ASP.NET Core a fost afectat de mai multe vulnerabilități critice de securitate. care afectează direct autentificarea, protecția datelor și serverul web Kestrel în sine. Dacă dezvoltați sau întrețineți aplicații pe .NET, acesta nu este doar un detaliu tehnic: vorbim despre vulnerabilități cu scoruri CVSS foarte mari (9,1 și chiar 9,9), capabilă să deschidă ușa către escaladările privilegiilor, uzurparea identității utilizatorilor și expunerea de informații extrem de sensibile.

Dincolo de zgomotul buletinelor de securitate, este esențial să înțelegem Ce anume eșuează în ASP.NET Core și ce pachete și versiuni sunt afectate?și cum ar trebui să reacționeze o echipă de dezvoltare modernă care lucrează cu cele mai bune practici CI/CD și DevSecOps, cum ar fi IDE-uri și instrumente cheie pentru testarea aplicațiilorVom analiza cele mai grave cazuri (inclusiv CVE-2026-40372 și CVE-2025-55315), vom analiza Măsuri de atenuare recomandate de Microsoft Și, dacă tot suntem la capitolul acesta, haideți să analizăm modelul de gestionare a erorilor și excepțiilor din ASP.NET Core, deoarece o încălcare a securității fără o bună observabilitate este ca și cum ai căuta acul în carul cu fân.

Vulnerabilitate critică în DataProtection: CVE-2026-40372

Unul dintre cele mai grave incidente care au afectat ecosistemul este CVE-2026-40372, o vulnerabilitate critică în Microsoft.AspNetCore.DataProtection, corectat de Microsoft cu o actualizare out-of-cycle în versiunea .NET 10.0.7. Severitatea nu este minoră: CVSS 3.1 din 9,1 (Recenzie) și exploatare la distanță fără autentificare.

Această vulnerabilitate afectează Versiunile 10.0.0 până la 10.0.6 ale pachetului Microsoft.AspNetCore.DataProtection NuGet și dependențele conexe, cum ar fi Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Problema constă într-o eroare foarte subtilă, dar devastatoare, în logica criptografică a cifrului autentificat gestionat de ASP.NET Core.

Componenta vulnerabilă calculează eticheta de validare HMAC pe octeții incorecți din sarcina utilă Și, în anumite cazuri, chiar elimină hash-ul generat. Această validare defectuoasă încalcă complet modelul de încredere așteptat: un atacator poate construi sarcini utile care par legitime, ocolind verificările de autenticitate ale sistemului de protecție a datelor.

Consecințele practice sunt deosebit de grave.Acest lucru se datorează faptului că DataProtection nu este utilizat doar pentru a cripta date arbitrare; se află în centrul multor mecanisme de securitate ASP.NET Core: cookie-uri de autentificare, token-uri anti-falsificare, TempData, stare OIDC și alte elemente care se bazează pe acest keyring. Dacă aceste obiecte pot fi falsificate sau decriptate, un atacator are o cale foarte directă către escaladarea privilegiilor.

Impact real: cookie-uri, token-uri și identitate compromisă

Defectul din DataProtection permite unui atacator falsificarea de sarcini utile care trec de verificări criptografice și, în unele scenarii, chiar decriptează datele protejate anteriorÎn mediile în care se utilizează API-urile ASP.NET Core Protection, acest lucru se traduce printr-o gamă foarte îngrijorătoare de atacuri.

Datele potențial expuse includ cookie-uri de autentificare, token-uri antifalsificare, TempData, starea OIDC și alte token-uri interneÎn cel mai rău caz, un atacator neautentificat ar putea fabrica un cookie sau un token care să îl identifice ca utilizator cu privilegii sporite, cum ar fi un administrator de aplicație sau un administrator de servicii interne.

Scenariul este agravat deoarece, dacă în timpul ferestrei vulnerabile atacatorul reușește obține un nivel ridicat de acces, poate determina aplicația să emită active legitime, dar obținute cu rea intenție: Chei API, token-uri de reîmprospătare a sesiunii, link-uri de resetare a parolei sau chei de acces persistenteToate aceste artefacte ar rămâne valide chiar și după actualizarea la .NET 10.0.7, cu excepția cazului în care se iau măsuri suplimentare.

Cu alte cuvinte, chiar dacă aplici plasturele, dacă nu reacționezi corect, Sistemul dumneavoastră ar putea fi în continuare expus la token-uri deja emise în condiții compromise.De aceea, Microsoft compară această defecțiune cu vulnerabilități istorice precum MS10-070, legate de problemele de padding-oracle din criptarea ASP.NET veche.

Microsoft a descoperit această regresie ca urmare a Rapoarte de la clienți care se confruntă cu erori de decriptare după instalarea .NET 10.0.6 în timpul patch-urilor de marți din aprilie. După investigarea incidentului (documentat inițial în problema aspnetcore #66335), echipa a descoperit că nu era doar o eroare funcțională, ci o breșă de securitate semnificativă care necesita un patch urgent în afara ciclului de funcționare.

Condiții de funcționare și medii afectate

Deși eșecul este critic, Nu toate mediile sunt expuse în mod implicit.Conform informațiilor oficiale, pentru a exploata CVE-2026-40372, trebuie îndeplinite mai multe condiții specifice legate de pachete și mediul de execuție.

Pe de o parte, aplicația trebuie să utilizeze versiunile vulnerabile ale pachetului Microsoft.AspNetCore.DataProtection (10.0.0 până la 10.0.6) sau biblioteci care o încarcă la momentul execuției. În plus, vulnerabilitatea are un impact mai mare asupra sistemelor de operare non-Windows, cum ar fi Linux și macOSAcest lucru se potrivește perfect cu implementarea tipică a ASP.NET Core în containere, orchestratoare și platforme cloud.

Vectorul de atac este executat în mod normal prin rețea, fără a fi nevoie de autentificare prealabilăAcest lucru îi sporește pericolul în aplicațiile expuse la internet. Atacatorul poate trimite sarcini utile special concepute ca și cum ar fi doar un alt client al sistemului, fără a necesita acreditări valide.

În practică, asta înseamnă că infrastructuri bazate pe microservicii, containere Docker și platforme PaaS Sistemele care se bazează pe DataProtection pentru a partaja chei sau starea de autentificare între instanțe sunt ținte prioritare. Dacă setul de chei nu a fost actualizat și rotit, există un risc real ca o singură compromitere să se transforme într-un acces persistent, dificil de detectat.

Din toate motivele menționate mai sus, echipele de securitate a aplicațiilor trebuie Analizați în detaliu ce servicii încarcă pachetul vulnerabil și pe ce sisteme de operare rulează, în loc să presupună că problema afectează doar scenarii foarte specifice.

Acțiuni urgente: actualizarea la .NET 10.0.7 și rotația cheilor

Principala recomandare a Microsoft este clară: Actualizați imediat pachetul Microsoft.AspNetCore.DataProtection la versiunea 10.0.7 și recompilați aplicațiile cu runtime-urile și SDK-urile corectate (de exemplu, .NET SDK 10.0.203 și runtime-urile asociate).

Pentru a confirma că mediul este actualizat corect, ar trebui să rulați dotnet –info și verificați dacă versiunea runtime este 10.0.7 corespunzător. Nu este suficient să instalați runtime-ul pe server; este esențial reconstruiți și redistribuiți aplicațiile folosind imagini sau pachete actualizate ale containerelor pentru a asigura legătura dintre codul de producție și binarele corectate.

Totuși, așa cum am menționat anterior, aplicarea patch-ului nu va remedia, în sine, daunele deja produse. Microsoft recomandă insistent să nu faceți acest lucru. rotiți brelocul DataProtection în medii care au fost expuse, pentru a invalida orice token, cookie sau credențial generat în mod rău intenționat în timpul ferestrei de vulnerabilitate.

Pe lângă actualizarea și rotirea cheilor, este prudent forțarea închiderii sesiunilor active (revocarea cookie-urilor de conectare, a token-urilor de acces etc.), solicitarea de reautentificări și activarea unui audit detaliat al jurnalului pentru a examina activitățile suspecte, în special accesul administrativ atipic, crearea de chei API, resetarea parolelor și operațiunile privilegiate.

Din perspectiva DevSecOps, acest incident întărește importanța integrării scanere de dependențe în lanțul CI/CD și pentru a activa alerte automate atunci când apar vulnerabilități critice în pachete terțe. Cu DataProtection, ca în cazul oricărei biblioteci criptografice, o mică modificare a comportamentului poate deteriora întregul model de securitate dacă nu este validat riguros.

O altă vulnerabilitate critică: falsificarea cererilor HTTP în Kestrel (CVE-2025-55315)

Pe lângă vulnerabilitatea din DataProtection, a fost raportată o alta. o eroare de securitate extrem de gravă în ASP.NET CoreDe data aceasta, accentul a fost pus pe serverul web Kestrel. Identificat ca CVE-2025-55315A fost clasificată drept o eroare de falsificare a cererii HTTP cu un scor de severitate de 9,9 peste 10.

Nucleul problemei este că Un atacator poate injecta o a doua cerere HTTP malițioasă în cadrul unei cereri aparent legitime.Acest lucru este tipic așa-numitelor atacuri de tip request smuggling sau de manipulare a framing-ului HTTP. Această tehnică poate fi utilizată pentru a ocoli controalele de securitate situate pe proxy-uri, load balancere sau pe serverul în sine și pentru a determina backend-ul să proceseze date pe care nu ar fi trebuit să le accepte niciodată.

Conform avertismentului Microsoft, impactul potențial implică acces la informații sensibile, furtul de acreditări, modificarea neautorizată a fișierelor și chiar posibilitatea de a provoca erori ale serverului care afectează disponibilitatea. Prin impactul direct asupra nivelului de transport HTTP, gama de atacuri este foarte largă, de la ocolirea autentificării până la redirecționarea traficului către rute interne.

Vulnerabilitatea afectează în mod specific Microsoft.AspNetCore.Server.Kestrel.Core Această vulnerabilitate există în anumite versiuni de ASP.NET Core și este considerată una dintre cele mai grave probleme de securitate cu care s-a confruntat platforma în ultimii ani. Din nou, este un vector exploatabil pentru atacatorii neautentificați, ceea ce crește semnificativ suprafața de atac.

Barry Dorrans, responsabil tehnic pentru securitate la .NET, a explicat că Un scor atât de mare reflectă cel mai rău scenariu posibil.Întrucât impactul real depinde în mare măsură de modul în care este construită fiecare aplicație, evaluarea se bazează pe premisa unei ocoliri a mecanismelor de securitate cu modificări ale domeniului de aplicare, acesta fiind tipul de eșec considerat inacceptabil în mediile corporative.

Versiuni și patch-uri afectate pentru Kestrel și ASP.NET Core

Pentru a rezolva problema CVE-2025-55315, Microsoft a lansat Actualizări de securitate specifice diferitelor ramuri ale .NET și ASP.NET Core, cuprinzând atât versiuni mai vechi, cât și versiuni mai noi, inclusiv ASP.NET Core 2.3, 8.0 și 9.0.

În mediile în care este utilizat .NET 8 sau o versiune ulterioarăAtenuarea recomandată implică aplicarea tuturor patch-urilor disponibile prin Microsoft Update și ulterior validați dacă runtime-urile și pachetele sunt în versiunea corectă. Este deosebit de important să verificați dacă aplicațiile sunt recompilate cu aceste versiuni și că imaginile de producție nu mai conțin fișiere binare vulnerabile.

În cazul proiectelor care sunt încă în curs de desfășurare .NET 2.3Microsoft indică faptul că este esențial Actualizați referința pachetului Microsoft.AspNet.Server.Kestrel.Core la versiunea 2.3.6Recompilați soluția și redistribuiți implementările. În caz contrar, Kestrel va continua să proceseze cererile cu logica defectuoasă care permite falsificarea cererilor HTTP.

Implementările care utilizează aplicații independente sau aplicații ambalate ca un singur fișier De asemenea, au obligația de a compila de la zero cu runtime-urile actualizate, altfel executabilul va conține în continuare codul vulnerabil. Este ușor să uiți acest detaliu dacă te bazezi prea mult pe simpla actualizare a gazdei.

Împreună cu actualizările cadrului în sine, Microsoft a lansat Patch-uri pentru Microsoft.AspNetCore.Server.Kestrel.Core și alte componente conexeAcest lucru își propune să consolideze robustețea analizării și gestionării cererilor HTTP. Pe scurt, nu este o singură soluție izolată, ci mai degrabă o îmbunătățire coordonată în mai multe puncte din stiva ASP.NET Core.

Actualizări critice suplimentare în ASP.NET Core și risc global

Dincolo de aceste cazuri specifice, Microsoft a lansat patch-uri critice pentru alte vulnerabilități din ASP.NET Core Aceste vulnerabilități pot duce la executarea de cod la distanță (RCE), escaladarea privilegiilor și atacuri de tip denial-of-service (DoS). Combinația acestor defecte arată clar că framework-ul, oricât de matur ar fi, nu este imun la regresii periculoase.

Aceste eșecuri afectează componentele cheie ale runtime-ului ASP.NET CoreAceasta include procesarea cererilor HTTP, middleware-ul de autentificare și autorizare și API-urile legate de serializarea și deserializarea datelor. În multe cazuri, atacatorii pot exploata intrări incorecte sau sarcini utile manipulate să declanșeze comportamente neașteptate.

Versiunile afectate corespund de obicei versiuni anterioare patch-urilor de securitate publicate în aprilie 2026Prin urmare, un audit al versiunilor este obligatoriu în toate mediile de producție care continuă să ruleze versiuni mai vechi. Lăsarea serverelor învechite este, în zilele noastre, o rețetă pentru dezastru.

Din perspectiva unei afaceri, neimplementarea acestor patch-uri poate avea consecințe foarte grave: pierderea confidențialității datelor, compromiterea integrității, indisponibilitatea serviciilor esențiale și un impact asupra reputației care necesită ani de zile pentru a se recupera. Organizațiile care se bazează pe ASP.NET Core pentru aplicații critice ar trebui să considere gestionarea patch-urilor ca un proces continuu, nu ca o sarcină unică.

Recomandarea generală a Microsoft este să Aplicați patch-uri imediat ce sunt disponibile și verificați setările de securitate ale mediilor.Consolidați monitorizarea activităților suspecte și revizuiți procesele de dezvoltare securizate pentru a minimiza probabilitatea introducerii vulnerabilităților în codul aplicației.

Gestionarea erorilor și excepțiilor în ASP.NET Core: o piesă cheie a puzzle-ului

Când vorbim despre securitate, ne gândim adesea doar la patch-uri și criptografie, dar Un sistem bun de gestionare a erorilor în ASP.NET Core este esențial. pentru a detecta, investiga și atenua incidentele. Framework-ul oferă mecanisme multiple pentru gestionarea excepțiilor, returnarea codurilor de stare corespunzătoare și expunerea răspunsurilor standard, cum ar fi ProblemDetails, în API-uri.

În mediile de dezvoltare, ASP.NET Core activează în mod implicit Pagina de excepții pentru dezvoltatori când sunt îndeplinite anumite condiții (de obicei, în mediul de dezvoltare). Această pagină este declanșată de middleware-ul DeveloperExceptionPageMiddleware, care este plasat la începutul canalului HTTP pentru a interceptează excepțiile netratate, atât sincrone, cât și asincroneși afișează informații detaliate.

Pagina de excepții pentru dezvoltatori poate include urme de stivă, parametri de șir de interogare, cookie-uri, anteturi HTTP și metadate ale punctului finalEste un instrument magnific în timpul dezvoltării, dar, logic, Nu ar trebui activat în producție.deoarece expunerea detaliilor interne le ușurează viața atacatorilor.

Într-un mediu de producție, practica recomandată este configurarea unui pagină de eroare personalizată folosind UseExceptionHandlerAcest middleware detectează excepțiile netratate, le înregistrează în jurnal și execută din nou cererea printr-o pipeline alternativă, de obicei indicând o rută precum /Error.

La reinstalarea conductelor, este important să rețineți că Middleware-urile pot fi invocate din nou cu același HttpContextPrin urmare, este recomandabil să curățați stările interne, să memorați în cache rezultatele sau să reutilizați datele deja citite (de exemplu, corpul cererii) pentru a evita cauzarea unor erori suplimentare. În plus, serviciile vizate rămân aceleași pe tot parcursul reexecuției.

Acces la excepții și control centralizat cu IExceptionHandler

Pentru a obține informații detaliate despre excepția care a declanșat pagina de eroare, ASP.NET Core expune caracteristica Caracteristică IExceptionHandlerPathPrin intermediul HttpContext.Features.Get Atât calea originală a cererii, cât și obiectul Exception în sine pot fi recuperate.

Un model comun în Razor Pages constă în Stochează RequestId-ul și un mesaj de eroare prietenos în modelul paginiiUtilizarea funcției IExceptionHandlerPathFeature vă permite să personalizați mesajul în funcție de tipul de excepție (de exemplu, FileNotFoundException) sau de calea care a cauzat eroarea. Acest lucru vă permite să afișați erori mai utile pentru utilizator fără a filtra detaliile interne.

Pe lângă abordarea bazată pe pagini sau specifică controlerului, ASP.NET Core oferă interfața IExceptionHandler ca mecanism centralizat de gestionare a excepțiilor. Implementările acestei interfețe sunt înregistrate cu AddExceptionHandler și sunt executate în ordine, returnând true când au gestionat excepția și false când preferă să delege comportamentul implicit.

Acest sistem facilitează, de exemplu, înregistrați erorile într-un sistem extern, aplicați logica condițională în funcție de tipul excepției. sau modificați răspunsul HTTP global fără a fi nevoie să atingeți fiecare controler individual. Începând cu .NET 10, middleware-ul de excepții vă permite, de asemenea, să configurați SuppressDiagnosticsCallback pentru a decide când să suprimați metricile și jurnalele în cazul unor excepții deja gestionate.

O altă opțiune foarte flexibilă este utilizarea unui lambda în UseExceptionHandlerAceasta implică accesarea directă a contextului, setarea codului de stare și a tipului de conținut și scrierea manuală a răspunsului. Puteți chiar utiliza IProblemDetailsService în cadrul acelei funcții lambda pentru a emite un răspuns standard ProblemDetails care descrie clar problema.

Pagini de cod de stare și răspunsuri ProblemDetails

În mod implicit, o aplicație ASP.NET Core Nu afișează pagini care sunt compatibile cu coduri de stare HTTP, cum ar fi 404.Pur și simplu returnează codul și un corp gol. Pentru a îmbogăți această experiență și a facilita depanarea, puteți activa middleware-ul paginii de cod de stare folosind UseStatusCodePages.

UseStatusCodePages acceptă mai multe moduri: Text simplu cu un mesaj generic, lambda pentru personalizarea completă a răspunsului sau variante care redirecționează sau reexecută conducta către un endpoint alternativ, cum ar fi UseStatusCodePagesWithRedirects și UseStatusCodePagesWithReExecute.

Cu UseStatusCodePagesWithRedirects, middleware-ul Emite o returnare 302 Found și redirecționează clientul către o adresă URL care de obicei oferă o vizualizare mai ușor de utilizat., returnând de obicei valoarea 200 OK. Această abordare are sens atunci când doriți ca bara de adrese să reflecte calea finală de eroare și nu doriți să păstrați codul de stare original.

UseStatusCodePagesWithReExecute, pe de altă parte, Codul de stare inițial nu se schimbăÎn schimb, reexecută cererea pe o rută diferită pentru a genera corpul răspunsului. URL-ul original este păstrat în bara de adrese a browserului, iar punctul de eroare poate recupera ruta și interogarea originală prin intermediul funcției IStatusCodeReExecuteFeature, ceea ce este foarte util pentru înregistrare în jurnal și depanare.

În domeniul API-urilor, ASP.NET Core a adoptat standardul Detalii problemă ca format standard pentru răspunsurile la eroriPrin înregistrarea AddProblemDetails în containerul de servicii, middleware-ul poate genera automat răspunsuri JSON cu câmpuri precum tip, titlu, stare și traceId atunci când apar erori client sau server fără un corp.

Acest comportament poate fi personalizat prin OpțiuniDetaliiProblemă.PersonalizareDetaliiProblemăAceasta implică adăugarea de extensii precum un identificator de nod (de exemplu, numele mașinii) sau alte metadate care ajută la urmărirea problemelor în medii distribuite. De asemenea, este posibil să se implementeze un IProblemDetailsWriter personalizat care decide ce stări să gestioneze și cum să serializeze detaliile.

Lecții pentru DevSecOps și cele mai bune practici continue

Cascada de vulnerabilități din ASP.NET Core și ecosistemul său .NET oferă câteva lecții cheie pentru orice echipă de dezvoltare serioasă: Dependențele de terți sunt un vector critic; criptografia implementată defectuos încalcă întregul model de încredere. iar mecanismele de autentificare au devenit o țintă principală pentru atacatori.

Din perspectiva DevSecOps, devine esențial integrarea analizei dependențelor În cadrul proceselor de integrare continuă/de dezvoltare (CI/CD), rulați teste de securitate continue și mențineți o vizibilitate clară asupra tuturor componentelor terțe încorporate în proiect. Instrumentele de analiză a compoziției software (SCA) și scanerele de vulnerabilități nu ar trebui să mai fie opționale, ci să devină parte a fluxului de lucru standard de integrare.

De asemenea, este vital să se consolideze Audituri de jurnal și monitorizare a evenimentelor de securitateAcest lucru este valabil mai ales în ceea ce privește autentificarea, emiterea de token-uri, crearea de sesiuni, modificările permisiunilor și operațiunile administrative. Fără o înregistrare în jurnal și alerte eficiente, o vulnerabilitate precum CVE-2026-40372 sau CVE-2025-55315 poate fi exploatată în mod silențios timp de luni de zile.

În ciuda complexității sale și a volumului de erori recente, ASP.NET Core rămâne un framework robust atâta timp cât este actualizat corespunzător și configurat în siguranță. Combinația dintre aplicarea rapidă a patch-urilor, rotația cheilor atunci când este necesar, bune practici de gestionare a erorilor și o abordare proactivă a securității Face diferența dintre o platformă robustă și o țintă ușoară pentru atacatori.

Întregul set de vulnerabilități și mecanisme de atenuare ne amintește că Securitatea în ASP.NET Core nu este doar o chestiune de aplicare ocazională de patch-uri.ci mai degrabă să presupunem o disciplină continuă: monitorizarea versiunilor pachetelor și a celor de execuție, gestionarea erorilor și excepțiilor, revizuirea răspunsurilor HTTP și a detaliilor ProblemDetail pe care le expunem și susținerea tuturor acestora cu procese DevSecOps mature, care ne permit să reacționăm rapid ori de câte ori apare o nouă eroare critică în ecosistemul .NET.

Articol asociat:

Listă de verificare a acțiunilor cheie în urma unui incident de securitate cibernetică

Isaac

Scriitor pasionat despre lumea octeților și a tehnologiei în general. Îmi place să îmi împărtășesc cunoștințele prin scriere și asta voi face în acest blog, să vă arăt toate cele mai interesante lucruri despre gadgeturi, software, hardware, tendințe tehnologice și multe altele. Scopul meu este să vă ajut să navigați în lumea digitală într-un mod simplu și distractiv.