Dela via

Isolerad lagring

  • Artikel

För skrivbordsappar är isolerad lagring en mekanism för datalagring som ger isolering och säkerhet genom att definiera standardiserade sätt att associera kod med sparade data. Standardisering ger även andra fördelar. Administratörer kan använda verktyg som utformats för att manipulera isolerad lagring för att konfigurera fillagringsutrymme, ange säkerhetsprinciper och ta bort oanvända data. Med isolerad lagring behöver koden inte längre unika sökvägar för att ange säkra platser i filsystemet, och data skyddas från andra program som bara har isolerad lagringsåtkomst. Hårdkodad information som anger var ett programs lagringsområde finns är onödig.

Viktigt!

Isolerad lagring är inte tillgänglig för Windows 8.x Store-appar. Använd i stället programdataklasserna i namnrymderna Windows.Storage som ingår i Windows Runtime-API:et för att lagra lokala data och filer. Mer information finns i Programdata i Windows Dev Center.

Datafack och lagringsplatser

När ett program lagrar data i en fil måste filnamnet och lagringsplatsen väljas noggrant för att minimera risken för att lagringsplatsen blir känd för ett annat program och därför är sårbart för skador. Utan ett standardsystem för att hantera dessa problem kan improviseringstekniker som minimerar lagringskonflikter vara komplexa och resultaten kan vara otillförlitliga.

Med isolerad lagring isoleras data alltid av användare och efter sammansättning. Autentiseringsuppgifter som ursprunget eller det starka namnet på sammansättningen avgör sammansättningsidentiteten. Data kan också isoleras av programdomänen med liknande autentiseringsuppgifter.

När du använder isolerad lagring sparar programmet data i ett unikt datafack som är associerat med någon aspekt av kodens identitet, till exempel dess utgivare eller signatur. Datautrymmet är en abstraktion, inte en specifik lagringsplats. den består av en eller flera isolerade lagringsfiler, som kallas butiker, som innehåller de faktiska katalogplatser där data lagras. Ett program kan till exempel ha ett associerat datafack, och en katalog i filsystemet implementerar det arkiv som faktiskt bevarar data för programmet. Data som sparas i arkivet kan vara alla typer av data, från användarinställningsinformation till programtillstånd. För utvecklaren är platsen för datautrymmet transparent. Butiker finns vanligtvis på klienten, men ett serverprogram kan använda isolerade lager för att lagra information genom att personifiera användaren för vars räkning den fungerar. Isolerad lagring kan också lagra information på en server med en användares centrala profil så att informationen överförs med den centrala användaren.

Kvoter för isolerad lagring

En kvot är en gräns för hur mycket isolerad lagring som kan användas. Kvoten innehåller byte av filutrymme samt de omkostnader som är associerade med katalogen och annan information i arkivet. Isolerad lagring använder behörighetskvoter, vilket är lagringsgränser som anges med hjälp IsolatedStoragePermission av objekt. Om du försöker skriva data som överskrider kvoten genereras ett IsolatedStorageException undantag. Säkerhetsprincip, som kan ändras med hjälp av .NET Framework Configuration Tool (Mscorcfg.msc), avgör vilka behörigheter som beviljas till kod. Kod som har beviljats IsolatedStoragePermission är begränsad till att inte använda mer lagringsutrymme än vad egenskapen UserQuota tillåter. Men eftersom kod kan kringgå behörighetskvoter genom att presentera olika användaridentiteter, fungerar behörighetskvoter som riktlinjer för hur kod ska bete sig snarare än som en fast gräns för kodbeteende.

Kvoter tillämpas inte på roaminglager. Därför krävs en något högre behörighetsnivå för att kod ska kunna använda dem. Uppräkningsvärdena AssemblyIsolationByRoamingUser och DomainIsolationByRoamingUser ange en behörighet att använda isolerad lagring för en roaminganvändare.

Säker åtkomst

Med isolerad lagring kan delvis betrodda program lagra data på ett sätt som styrs av datorns säkerhetsprincip. Detta är särskilt användbart för nedladdade komponenter som en användare kanske vill köra försiktigt. Säkerhetsprincipen beviljar sällan den här typen av kodbehörighet när du kommer åt filsystemet med hjälp av standard-I/O-mekanismer. Men som standard beviljas kod som körs från den lokala datorn, ett lokalt nätverk eller Internet rätten att använda isolerad lagring.

Administratörer kan begränsa hur mycket isolerad lagring ett program eller en användare har tillgängligt, baserat på en lämplig förtroendenivå. Dessutom kan administratörer ta bort en användares beständiga data helt. Om du vill skapa eller komma åt isolerad lagring måste koden beviljas lämplig IsolatedStorageFilePermission behörighet.

För att få åtkomst till isolerad lagring måste koden ha alla nödvändiga interna operativsystemrättigheter för plattformen. Åtkomstkontrollistor (ACL:er) som styr vilka användare som har behörighet att använda filsystemet måste vara uppfyllda. .NET-program har redan operativsystemrättigheter för åtkomst till isolerad lagring om de inte utför (plattformsspecifik) personifiering. I det här fallet ansvarar programmet för att säkerställa att den personifierade användaridentiteten har rätt operativsystemrättigheter för åtkomst till isolerad lagring. Den här åtkomsten är ett praktiskt sätt för kod som körs eller laddas ned från webben att läsa och skriva till ett lagringsområde som är relaterat till en viss användare.

För att styra åtkomsten till isolerad lagring använder IsolatedStorageFilePermission den vanliga språkkörningen objekt. Varje objekt har egenskaper som anger följande värden:

  • Tillåten användning, vilket anger vilken typ av åtkomst som tillåts. Värdena är medlemmar i IsolatedStorageContainment uppräkningen. Mer information om dessa värden finns i tabellen i nästa avsnitt.

  • Lagringskvot, enligt beskrivningen i föregående avsnitt.

Körningen kräver IsolatedStorageFilePermission behörighet när koden först försöker öppna ett arkiv. Den bestämmer om den här behörigheten ska beviljas, baserat på hur mycket koden är betrodd. Om behörigheten beviljas bestäms de tillåtna användnings- och lagringskvotvärdena av säkerhetsprincipen och av kodens begäran om IsolatedStorageFilePermission. Säkerhetsprincip anges med hjälp av konfigurationsverktyget för .NET Framework (Mscorcfg.msc). Alla anropare i samtalsstacken kontrolleras för att säkerställa att varje anropare har minst lämplig tillåten användning. Körningen kontrollerar också kvoten som har införts för koden som öppnade eller skapade det arkiv där filen ska sparas. Om dessa villkor uppfylls beviljas behörighet. Kvoten kontrolleras igen varje gång en fil skrivs till arkivet.

Programkod krävs inte för att begära behörighet eftersom den vanliga språkkörningen beviljar det som IsolatedStorageFilePermission är lämpligt baserat på säkerhetsprincipen. Det finns dock goda skäl att begära specifika behörigheter som ditt program behöver, inklusive IsolatedStorageFilePermission.

Tillåtna användnings- och säkerhetsrisker

Den tillåtna användning som anges av IsolatedStorageFilePermission avgör i vilken grad koden ska tillåtas att skapa och använda isolerad lagring. Följande tabell visar hur den tillåtna användningen som anges i behörigheten motsvarar typer av isolering och sammanfattar de säkerhetsrisker som är associerade med varje tillåten användning.

Tillåten användning Isoleringstyper Säkerhetspåverkan
None Ingen isolerad lagringsanvändning tillåts. Det finns ingen säkerhetspåverkan.
DomainIsolationByUser Isolering efter användare, domän och sammansättning. Varje sammansättning har ett separat underlager i domänen. Butiker som använder den här behörigheten är också implicit isolerade av datorn. Den här behörighetsnivån lämnar resurser öppna för obehörig överanvändning, även om tvingande kvoter gör det svårare. Detta kallas för en överbelastningsattack.
DomainIsolationByRoamingUser Samma som DomainIsolationByUser, men arkivet sparas på en plats som kommer att flyttas om centrala användarprofiler är aktiverade och kvoter inte tillämpas. Eftersom kvoter måste inaktiveras är lagringsresurser mer sårbara för överbelastningsattacker.
AssemblyIsolationByUser Isolering efter användare och sammansättning. Butiker som använder den här behörigheten är också implicit isolerade av datorn. Kvoter tillämpas på den här nivån för att förhindra överbelastningsattacker. Samma sammansättning i en annan domän kan komma åt det här arkivet, vilket öppnar möjligheten att information kan läcka mellan program.
AssemblyIsolationByRoamingUser Samma som AssemblyIsolationByUser, men arkivet sparas på en plats som kommer att flyttas om centrala användarprofiler är aktiverade och kvoter inte tillämpas. På samma sätt som i AssemblyIsolationByUser, men utan kvoter, ökar risken för överbelastningsattacker.
AdministerIsolatedStorageByUser Isolering efter användare. Vanligtvis använder endast administrativa verktyg eller felsökningsverktyg den här behörighetsnivån. Med åtkomst med den här behörigheten kan kod visa eller ta bort någon av en användares isolerade lagringsfiler eller kataloger (oavsett sammansättningsisolering). Risker omfattar, men är inte begränsade till, läckande information och dataförlust.
UnrestrictedIsolatedStorage Isolering av alla användare, domäner och sammansättningar. Vanligtvis använder endast administrativa verktyg eller felsökningsverktyg den här behörighetsnivån. Den här behörigheten skapar potentialen för en total kompromiss av alla isolerade butiker för alla användare.

Säkerhet för isolerade lagringskomponenter när det gäller ej betrodda data

Det här avsnittet gäller för följande ramverk:

  • .NET Framework (alla versioner)
  • .NET Core 2.1+
  • .NET 5+

.NET Framework och .NET Core erbjuder isolerad lagring som en mekanism för att bevara data för en användare, ett program eller en komponent. Det här är en äldre komponent som främst är utformad för nu inaktuella säkerhetsscenarier för kodåtkomst.

Olika isolerade lagrings-API:er och verktyg kan användas för att läsa data över förtroendegränser. Till exempel kan läsning av data från ett datoromfattande omfång aggregera data från andra, eventuellt mindre betrodda användarkonton på datorn. Komponenter eller program som läser från datoromfattande isolerade lagringsomfång bör vara medvetna om konsekvenserna av att läsa dessa data.

Säkerhetskänsliga API:er som kan läsas från hela datoromfånget

Komponenter eller program som anropar något av följande API:er läse från det datoromfattande omfånget:

Det isolerade lagringsverktyget storeadm.exe påverkas om det anropas med växeln /machine , enligt följande kod:

storeadm.exe /machine [any-other-switches]

Det isolerade lagringsverktyget tillhandahålls som en del av Visual Studio och .NET Framework SDK.

Om programmet inte omfattar anrop till föregående API:er, eller om arbetsflödet inte omfattar anrop storeadm.exe på det här sättet, gäller inte det här dokumentet.

Påverkan i miljöer med flera användare

Som tidigare nämnts kommer säkerhetspåverkan från dessa API:er från data som skrivits från en förtroendemiljö att läsas från en annan förtroendemiljö. Isolerad lagring använder vanligtvis en av tre platser för att läsa och skriva data:

  1. %LOCALAPPDATA%\IsolatedStorage\: Till exempel C:\Users\<username>\AppData\Local\IsolatedStorage\, för User omfång.
  2. %APPDATA%\IsolatedStorage\: Till exempel C:\Users\<username>\AppData\Roaming\IsolatedStorage\, för User|Roaming omfång.
  3. %PROGRAMDATA%\IsolatedStorage\: Till exempel C:\ProgramData\IsolatedStorage\, för Machine omfång.

De två första platserna är isolerade per användare. Windows ser till att olika användarkonton på samma dator inte kan komma åt varandras användarprofilmappar. Två olika användarkonton User som använder eller User|Roaming lagrar ser inte varandras data och kan inte störa varandras data.

Den tredje platsen delas mellan alla användarkonton på datorn. Olika konton kan läsa från och skriva till den här platsen och de kan se varandras data.

De föregående sökvägarna kan variera beroende på vilken version av Windows som används.

Överväg nu ett system med flera användare med två registrerade användare Mallory och Bob. Mallory har möjlighet att komma åt sin användarprofilkatalog C:\Users\Mallory\och hon kan komma åt den delade lagringsplatsen C:\ProgramData\IsolatedStorage\för hela datorn . Hon kan inte komma åt Bobs användarprofilkatalog C:\Users\Bob\.

Om Mallory vill attackera Bob kan hon skriva data till lagringsplatsen för hela datorn och sedan försöka påverka Bob till att läsa från det datoromfattande lagret. När Bob kör en app som läser från den här butiken fungerar appen på de data som Mallory placerar där, men inifrån kontexten för Bobs användarkonto. Resten av det här dokumentet beskriver olika attackvektorer och vilka steg appar kan göra för att minimera risken för dessa attacker.

Kommentar

För att en sådan attack ska äga rum kräver Mallory:

  • Ett användarkonto på datorn.
  • Möjligheten att placera en fil på en känd plats i filsystemet.
  • Vet att Bob någon gång kommer att köra en app som försöker läsa dessa data.

Det här är inte hotvektorer som gäller för vanliga skrivbordsmiljöer med en användare, till exempel hemdatorer eller företagsarbetsstationer med en anställd.

Behörighetshöjning

En höjning av privilegier uppstår när Bobs app läser Mallorys fil och automatiskt försöker vidta vissa åtgärder baserat på innehållet i nyttolasten. Överväg en app som läser innehållet i ett startskript från den datoromfattande butiken och skickar innehållet till Process.Start. Om Mallory kan placera ett skadligt skript i den datoromfattande butiken när Bob startar sin app:

  • Hans app parsar och startar Mallorys skadliga skript inom ramen för Bobs användarprofil.
  • Mallory får åtkomst till Bobs konto på den lokala datorn.

Denial of Service

En denial of service-attack inträffar när Bobs app läser Mallorys fil och kraschar eller på annat sätt slutar fungera korrekt. Överväg igen den app som nämndes tidigare, som försöker parsa ett startskript från den datoromfattande butiken. Om Mallory kan placera en fil med felaktigt innehåll i det datoromfattande arkivet kan hon:

  • Få Bobs app att utlösa ett undantag tidigt i startsökvägen.
  • Förhindra att appen startas på grund av undantaget.

Hon har sedan nekat Bob möjligheten att starta appen under sitt eget användarkonto.

Avslöjande av information

En informationsupplysningsattack inträffar när Mallory kan lura Bob att avslöja innehållet i en fil som Mallory normalt inte har åtkomst till. Tänk på att Bob har en hemlig fil C:\Users\Bob\secret.txt som Mallory vill läsa. Hon känner till sökvägen till den här filen, men hon kan inte läsa den eftersom Windows förbjuder henne från att få åtkomst till Bobs användarprofilkatalog.

I stället placerar Mallory en hård länk i den maskinomfattande butiken. Det här är en speciell typ av fil som i sig inte innehåller något innehåll, snarare pekar den på en annan fil på disken. Om du försöker läsa den hårda länkfilen läss i stället innehållet i filen som länken riktar in sig på. När mallory har skapat den hårda länken kan hon fortfarande inte läsa filinnehållet eftersom hon inte har åtkomst till målet (C:\Users\Bob\secret.txt) för länken. Bob har dock åtkomst till den här filen.

När Bobs app läser från den datoromfattande butiken läser den nu oavsiktligt innehållet i hans secret.txt fil, precis som om själva filen hade funnits i den datoromfattande butiken. När Bobs app avslutas, om den försöker att återaktivera filen till det datoromfattande arkivet, placeras en faktisk kopia av filen i katalogen *C:\ProgramData\IsolatedStorage*. Eftersom den här katalogen kan läsas av alla användare på datorn kan Mallory nu läsa innehållet i filen.

Metodtips för att försvara sig mot dessa attacker

Viktigt: Om din miljö har flera ömsesidigt ej betrodda användare ska du inte anropa API IsolatedStorageFile.GetEnumerator(IsolatedStorageScope.Machine) :et eller anropa verktyget storeadm.exe /machine /list. Båda dessa förutsätter att de arbetar med betrodda data. Om en angripare kan skapa en skadlig nyttolast i det datoromfattande arkivet kan den nyttolasten leda till en utökade privilegieringsattack i kontexten för den användare som kör dessa kommandon.

Om du arbetar i en miljö med flera användare bör du överväga att använda isolerade lagringsfunktioner som är inriktade på datoromfånget. Om en app måste läsa data från en datoromfattande plats föredrar du att läsa data från en plats som endast kan skrivas av administratörskonton. Katalogen %PROGRAMFILES% och HKLM registreringsdatafilen är exempel på platser som endast kan skrivas av administratörer och kan läsas av alla. Data som lästs från dessa platser anses därför vara tillförlitliga.

Om en app måste använda datoromfånget i en miljö med flera användare kontrollerar du innehållet i alla filer som du läser från det datoromfattande arkivet. Om appen deserialiserar objektdiagram från dessa filer bör du överväga att använda säkrare serialiserare som XmlSerializer i stället för farliga serialiserare som BinaryFormatter eller NetDataContractSerializer. Var försiktig med djupt kapslade objektdiagram eller objektdiagram som utför resursallokering baserat på filinnehållet.

Isolerade lagringsplatser

Ibland kan det vara bra att verifiera en ändring av isolerad lagring med hjälp av operativsystemets filsystem. Du kanske också vill veta var isolerade lagringsfiler finns. Den här platsen skiljer sig beroende på operativsystemet. I följande tabell visas rotplatserna där isolerad lagring skapas på några vanliga operativsystem. Leta efter Microsoft\IsolatedStorage-kataloger under den här rotplatsen. Du måste ändra mappinställningarna för att visa dolda filer och mappar för att kunna se isolerad lagring i filsystemet.

Operativsystem Plats i filsystemet
Windows 2000, Windows XP, Windows Server 2003 (uppgradering från Windows NT 4.0) Roaming-aktiverade butiker =

<SYSTEMROOT>\Profiles\<user>\Application Data

Icke-roaming-butiker =

<SYSTEMROOT>\Profiles\<user>\Local Settings\Application Data
Windows 2000 – ren installation (och uppgraderingar från Windows 98 och Windows NT 3.51) Roaming-aktiverade butiker =

<SYSTEMDRIVE>\Dokument och inställningar\<user>\Application Data

Icke-roaming-butiker =

<SYSTEMDRIVE>\Dokument och inställningar\<användare>\Lokala inställningar\Programdata
Windows XP, Windows Server 2003 – ren installation (och uppgraderingar från Windows 2000 och Windows 98) Roaming-aktiverade butiker =

<SYSTEMDRIVE>\Dokument och inställningar\<user>\Application Data

Icke-roaming-butiker =

<SYSTEMDRIVE>\Dokument och inställningar\<användare>\Lokala inställningar\Programdata
Windows 8, Windows 7, Windows Server 2008, Windows Vista Roaming-aktiverade butiker =

<SYSTEMDRIVE>\Users\<user>\AppData\Roaming

Icke-roaming-butiker =

<SYSTEMDRIVE>\Users\<user>\AppData\Local

Skapa, räkna upp och ta bort isolerad lagring

.NET tillhandahåller tre klasser i System.IO.IsolatedStorage namnområdet som hjälper dig att utföra uppgifter som omfattar isolerad lagring:

Med de isolerade lagringsklasserna kan du skapa, räkna upp och ta bort isolerad lagring. Metoderna för att utföra dessa uppgifter är tillgängliga via objektet IsolatedStorageFile . Vissa åtgärder kräver att du har den IsolatedStorageFilePermission behörighet som representerar rätten att administrera isolerad lagring. Du kan också behöva ha operativsystemsbehörighet för att få åtkomst till filen eller katalogen.

En serie exempel som visar vanliga isolerade lagringsuppgifter finns i avsnitten om instruktioner som anges i Relaterade ämnen.

Scenarier för isolerad lagring

Isolerad lagring är användbart i många situationer, inklusive följande fyra scenarier:

  • Nedladdade kontroller. Hanterade kodkontroller som laddas ned från Internet får inte skriva till hårddisken via normala I/O-klasser, men de kan använda isolerad lagring för att bevara användarnas inställningar och programtillstånd.

  • Delad komponentlagring. Komponenter som delas mellan program kan använda isolerad lagring för att ge kontrollerad åtkomst till datalager.

  • Serverlagring. Serverprogram kan använda isolerad lagring för att tillhandahålla enskilda butiker för ett stort antal användare som skickar begäranden till programmet. Eftersom isolerad lagring alltid är åtskild av användaren måste servern personifiera den användare som gör begäran. I det här fallet isoleras data baserat på huvudnamnets identitet, vilket är samma identitet som programmet använder för att skilja mellan sina användare.

  • Roaming. Program kan också använda isolerad lagring med centrala användarprofiler. På så sätt kan en användares isolerade butiker vandra med profilen.

Använd inte isolerad lagring i följande situationer:

  • Om du vill lagra hemligheter med högt värde, till exempel okrypterade nycklar eller lösenord, eftersom isolerad lagring inte skyddas från mycket betrodd kod, från ohanterad kod eller från betrodda användare av datorn.

  • För att lagra kod.

  • Lagra konfigurations- och distributionsinställningar som administratörer styr. (Användarinställningar anses inte vara konfigurationsinställningar eftersom administratörer inte kontrollerar dem.)

Många program använder en databas för att lagra och isolera data, i vilket fall en eller flera rader i en databas kan representera lagring för en viss användare. Du kan välja att använda isolerad lagring i stället för en databas när antalet användare är litet, när kostnaderna för att använda en databas är betydande eller när det inte finns någon databasfunktion. Om programmet dessutom kräver lagring som är mer flexibel och komplex än vad en rad i en databas tillhandahåller, kan isolerad lagring vara ett genomförbart alternativ.

Title Description
Typer av isolering Beskriver de olika typerna av isolering.
Gör så här: Hämta butiker för isolerad lagring Innehåller ett exempel på hur du använder IsolatedStorageFile klassen för att hämta ett lager isolerat av användare och sammansättning.
Gör så här: Räkna upp lagringslager för isolerad lagring Visar hur du använder IsolatedStorageFile.GetEnumerator metoden för att beräkna storleken på all isolerad lagring för användaren.
Gör så här: Ta bort butiker i isolerad lagring Visar hur du använder metoden på IsolatedStorageFile.Remove två olika sätt för att ta bort isolerade butiker.
Anvisningar: Förutse out-of-space-förhållanden med isolerad lagring Visar hur du mäter återstående utrymme i ett isolerat lager.
Anvisningar: Skapa filer och kataloger i isolerad lagring Innehåller några exempel på hur du skapar filer och kataloger i ett isolerat arkiv.
Anvisningar: Hitta befintliga filer och kataloger i isolerad lagring Visar hur du läser katalogstrukturen och filerna i isolerad lagring.
Anvisningar: Läsa och skriva till filer i isolerad lagring Innehåller ett exempel på hur du skriver en sträng till en isolerad lagringsfil och läser tillbaka den.
Anvisningar: Ta bort filer och kataloger i isolerad lagring Visar hur du tar bort isolerade lagringsfiler och kataloger.
Fil- och stream-I/O Förklarar hur du kan utföra synkron och asynkron fil- och dataströmåtkomst.

Referens