Dela via

Deserialiseringsrisker vid användning av BinaryFormatter och relaterade typer

  • Artikel

Den här artikeln gäller för följande typer:

Den här artikeln gäller för följande .NET-implementeringar:

  • .NET Framework alla versioner
  • .NET Core 2.1 – 3.1
  • .NET 5 och senare

Varning

Typen BinaryFormatter är farlig och rekommenderas inte för databehandling. Program bör sluta använda BinaryFormatter så snart som möjligt, även om de anser att de data som de bearbetar är tillförlitliga. BinaryFormatter är osäker och kan inte göras säker.

Kommentar

Från och med .NET 9 utlöser den inbyggda BinaryFormatter implementeringen undantag vid användning, även med de inställningar som tidigare aktiverade dess användning. Dessa inställningar tas också bort. Mer information finns i migreringsguiden för BinaryFormatter.

Sårbarheter för deserialisering

Sårbarheter för deserialisering är en hotkategori där nyttolaster för begäran behandlas osäkert. En angripare som utnyttjar dessa säkerhetsrisker mot en app kan orsaka DoS (Denial of Service), avslöjande av information eller fjärrkörning av kod i målappen. Den här riskkategorin gör konsekvent OWASP till topp 10. Målen omfattar appar som skrivits på en mängd olika språk, inklusive C/C++, Java och C#.

I .NET är det största riskmålet appar som använder BinaryFormatter typen för att deserialisera data. BinaryFormatter används ofta i hela .NET-ekosystemet på grund av dess kraft och dess användarvänlighet. Samma kraft ger dock angripare möjlighet att påverka kontrollflödet i målappen. Lyckade attacker kan leda till att angriparen kan köra kod inom ramen för målprocessen.

Som en enklare analogi antar vi att anrop BinaryFormatter.Deserialize över en nyttolast motsvarar tolkningen av nyttolasten som en fristående körbar fil och startar den.

Säkerhetsrisker för BinaryFormatter

Varning

Metoden BinaryFormatter.Deserialize är aldrig säker när den används med ej betrodda indata. Vi rekommenderar starkt att konsumenterna i stället överväger att använda något av de alternativ som beskrivs senare i den här artikeln.

BinaryFormatter implementerades innan sårbarheter för deserialisering var en välförstådd hotkategori. Därför följer koden inte moderna metodtips. Metoden Deserialize kan användas som vektor för angripare för att utföra DoS-attacker mot användning av appar. Dessa attacker kan göra att appen inte svarar eller resultera i oväntad processavslutning. Den här attackkategorin kan inte minimeras med en SerializationBinder eller någon annan BinaryFormatter konfigurationsväxel. .NET anser att det här beteendet är avsiktligt och utfärdar ingen koduppdatering för att ändra beteendet.

BinaryFormatter.Deserialize kan vara mottagliga för andra attackkategorier, till exempel avslöjande av information eller fjärrkörning av kod. Användning av funktioner som en anpassad SerializationBinder kan vara otillräcklig för att minimera dessa risker på ett korrekt sätt. Det finns en möjlighet att en angripare upptäcker en ny exploatering som kringgår befintliga åtgärder. .NET åtar sig inte att publicera korrigeringar som svar på sådana förbikopplingar. Dessutom kan det vara tekniskt omöjligt att utveckla eller distribuera sådana korrigeringar. Du bör utvärdera dina scenarier och överväga din potentiella exponering för dessa risker.

Vi rekommenderar att BinaryFormatter användarna utför enskilda riskbedömningar i sina appar. Det är konsumentens enda ansvar att avgöra om du vill använda BinaryFormatter. Om du överväger att använda den bör du riskbedöpa säkerhets-, teknik-, ryktes-, juridiska och regelmässiga konsekvenser.

Föredragna alternativ

.NET erbjuder flera inbyggda serialiserare som kan hantera ej betrodda data på ett säkert sätt:

Farliga alternativ

Undvik följande serialiserare:

De föregående serialiserarna utför alla obegränsad polymorfa deserialisering och är farliga, precis som BinaryFormatter.

Riskerna med att anta att data är tillförlitliga

Ofta kan en apputvecklare tro att de endast bearbetar betrodda indata. Det säkra indatafallet gäller i vissa sällsynta fall. Men det är mycket vanligare att en nyttolast korsar en förtroendegräns utan att utvecklaren inser det.

Överväg en lokal server där anställda använder en skrivbordsklient från sina arbetsstationer för att interagera med tjänsten. Det här scenariot kan ses naivt som en "säker" konfiguration där användningen BinaryFormatter är acceptabel. Det här scenariot presenterar dock en vektor för skadlig kod som får åtkomst till en enskild anställds dator för att kunna spridas i hela företaget. Den skadliga koden kan utnyttja företagets användning av BinaryFormatter för att flytta i sidled från medarbetarens arbetsstation till serverdelsservern. Den kan sedan exfiltera företagets känsliga data. Sådana data kan omfatta affärshemligheter eller kunddata.

Överväg även en app som använder BinaryFormatter för att spara tillstånd. Detta kan först verka vara ett säkert scenario, eftersom läsning och skrivning av data på din egen hårddisk utgör ett mindre hot. Det är dock vanligt att dela dokument via e-post eller internet, och de flesta slutanvändare skulle inte uppfatta öppnandet av dessa nedladdade filer som ett riskabelt beteende.

Det här scenariot kan utnyttjas till skändlig effekt. Om appen är ett spel riskerar användare som delar spara filer omedvetet sig själva. Utvecklarna själva kan också vara målinriktade. Angriparen kan skicka e-post till utvecklarnas tekniska support, bifoga en skadlig datafil och be supportpersonalen att öppna den. Den här typen av angrepp kan ge angriparen fotfäste i företaget.

Ett annat scenario är var datafilen lagras i molnlagring och synkroniseras automatiskt mellan användarens datorer. En angripare som kan få åtkomst till molnlagringskontot kan förgifta datafilen. Den här datafilen synkroniseras automatiskt till användarens datorer. Nästa gång användaren öppnar datafilen körs angriparens nyttolast. Angriparen kan därför utnyttja en molnlagringskontokompromiss för att få fullständig kodkörningsbehörighet.

Överväg en app som flyttas från en skrivbordsinstallationsmodell till en molnbaserad modell. I det här scenariot ingår appar som flyttas från en skrivbordsapp eller en omfattande klientmodell till en webbaserad modell. Alla hotmodeller som ritas för skrivbordsappen gäller inte nödvändigtvis för den molnbaserade tjänsten. Hotmodellen för skrivbordsappen kan avfärda ett visst hot som "inte intressant för klienten att attackera sig själv". Men samma hot kan bli intressant när en fjärranvändare (klienten) angriper själva molntjänsten.

Kommentar

I allmänna termer är avsikten med serialisering att överföra ett objekt till eller från en app. En hotmodelleringsövning markerar nästan alltid den här typen av dataöverföring som att korsa en förtroendegräns.

Se även