Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Även om Windows Presentation Foundation (WPF) tillhandahåller en mängd olika säkerhetstjänster utnyttjar den även säkerhetsfunktionerna i den underliggande plattformen, som omfattar operativsystemet, CLR och Internet Explorer. Dessa lager kombineras för att ge WPF en stark, djupskyddsmodell som försöker undvika en enskild felpunkt, enligt följande bild:
Resten av det här avsnittet beskriver funktionerna i vart och ett av dessa lager som specifikt gäller WPF.
Varning
Code Access Security (CAS) stöds inte av modern .NET, det är ett .NET Framework-begrepp. Alla CAS-relaterade funktioner behandlas under antagandet om fullständigt förtroende. Mer information finns i Skillnader med WPF .NET – Kodåtkomstsäkerhet.
Säkerhet för operativsystem
Kärnan i Windows innehåller flera säkerhetsfunktioner som utgör säkerhetsgrunden för alla Windows-program, inklusive de som skapats med WPF. I det här avsnittet beskrivs bredden på dessa säkerhetsfunktioner som är viktiga för WPF, samt hur WPF integreras med dem för att ge ytterligare skydd på djupet.
Microsoft Windows XP Service Pack 2 (SP2)
Förutom en allmän granskning och förstärkning av Windows finns det tre viktiga funktioner från Windows XP SP2 som vi kommer att diskutera i det här avsnittet:
/GS kompilering
Microsoft Windows Update.
/GS-kompilering
Windows XP SP2 ger skydd genom att omkompilera många kärnsystembibliotek, inklusive alla WPF-beroenden som CLR, för att minimera buffertöverskridningar. Detta uppnås med hjälp av /GS-parametern med kommandoradskompilatorn C/C++. Även om buffertöverskridanden uttryckligen bör undvikas, ger /GS-kompilering ett exempel på ett skydd på djupet mot potentiella sårbarheter som oavsiktligt eller skadligt skapas av dem.
Tidigare har buffertöverskridanden varit orsaken till många säkerhetsexploateringar med hög påverkan. En buffertöverskridning uppstår när en angripare drar nytta av en säkerhetsrisk för kod som tillåter inmatning av skadlig kod som skriver förbi gränserna för en buffert. Detta gör att en angripare kan kapa processen där koden körs genom att skriva över returadressen för en funktion så att angriparens kod exekveras. Resultatet är skadlig kod som kör godtycklig kod med samma behörigheter som den kapade processen.
På hög nivå skyddar -GS-kompilatorflaggan mot vissa potentiella buffertöverskridanden genom att mata in en särskild säkerhetscookie för att skydda returadressen för en funktion som har lokala strängbuffertar. När en funktion har returnerats jämförs säkerhetscookien med dess tidigare värde. Om värdet har ändrats kan en buffertöverskridning ha inträffat och processen stoppas med ett feltillstånd. Om du stoppar processen förhindras körning av potentiellt skadlig kod. Mer information finns i -GS (buffertsäkerhetskontroll).
WPF kompileras med flaggan /GS för att lägga till ännu ett lager av skydd i WPF-program.
Windows Vista
WPF-användare i Windows Vista kommer att dra nytta av operativsystemets ytterligare säkerhetsförbättringar, inklusive "Least-Privilege Användaråtkomst", kodintegritetskontroller och privilegierisolering.
Användarkontokontroll (UAC)
I dag brukar Windows-användare köras med administratörsbehörighet eftersom många program kräver dem för installation eller körning, eller både och. Att kunna skriva standardprograminställningar till registret är ett exempel.
Att köra med administratörsbehörighet innebär verkligen att program körs från processer som beviljas administratörsbehörighet. Säkerhetspåverkan av detta är att all skadlig kod som kapar en process som körs med administratörsbehörighet automatiskt ärver dessa privilegier, inklusive åtkomst till kritiska systemresurser.
Ett sätt att skydda mot det här säkerhetshotet är att köra program med minsta möjliga behörighet. Detta kallas principen för lägsta behörighet och är en viktig funktion i Windows-operativsystemet. Den här funktionen kallas UAC (User Account Control) och används av Windows UAC på två viktiga sätt:
Om du vill köra de flesta program med UAC-behörigheter som standard, även om användaren är administratör. endast program som behöver administratörsbehörighet körs med administratörsbehörighet. För att köra med administratörsbehörigheter måste applikationer uttryckligen markeras i antingen sitt applikationsmanifest eller som en post i säkerhetspolicyn.
För att tillhandahålla kompatibilitetslösningar som virtualisering. Många program försöker till exempel skriva till begränsade platser som C:\Program Files. För program som körs under UAC finns det en alternativ plats per användare som inte kräver administratörsbehörighet att skriva till. För program som körs under UAC virtualiserar UAC C:\Program Files så att program som tror att de skriver till den faktiskt skriver till den alternativa platsen per användare. Med den här typen av kompatibilitetsarbete kan operativsystemet köra många program som inte tidigare kunde köras i UAC.
Kodintegritetskontroller
Windows Vista innehåller djupare kodintegritetskontroller för att förhindra att skadlig kod matas in i systemfiler eller i kerneln vid belastning/körning. Detta går utöver systemfilskyddet.
Begränsad rättighetsprocess för Browser-Hosted-ansökningar
WPF-applikationer som är webbläsarbaserade körs inom sandlådemiljön i Internetzonen. WPF-integrering med Microsoft Internet Explorer utökar det här skyddet med ytterligare support.
Varning
XBAP:er kräver att äldre webbläsare används, till exempel Internet Explorer och gamla versioner av Firefox. Dessa äldre webbläsare stöds vanligtvis inte i Windows 10 och Windows 11. Moderna webbläsare stöder inte längre den teknik som krävs för XBAP-appar på grund av säkerhetsrisker. Plugin-program som aktiverar XBAP:er stöds inte längre. Mer information finns i Vanliga frågor och svar om WPF-webbläsarbaserade program (XBAP).
Eftersom XAML-webbläsarprogram (XBAP: er) i allmänhet sandboxas av behörighetsuppsättningen i zonen Internet, skadar inte borttagningen av dessa privilegier XAML-webbläsarprogram (XBAPs) ur ett kompatibilitetsperspektiv. I stället skapas ett ytterligare lager av försvar i djupet. Om ett begränsat program kan utnyttja andra lager och övertar processen, kommer den ändå bara ha begränsade rättigheter.
Se Använda ett Least-Privileged användarkonto.
Common Language Runtime Säkerhet
Common Language Runtime (CLR) erbjuder ett antal viktiga säkerhetsfördelar som validering och verifiering, Code Access Security (CAS) och den säkerhetskritiska metoden.
Validering och verifiering
För att tillhandahålla sammansättningsisolering och integritet använder CLR en valideringsprocess. CLR-validering säkerställer att sammansättningar isoleras genom att deras PE-filformat (Portable Executable) verifieras för adresser som pekar utanför sammansättningen. CLR-validering validerar också integriteten för de metadata som är inbäddade i en sammansättning.
För att säkerställa typsäkerhet, hjälpa till att förhindra vanliga säkerhetsproblem (t.ex. buffertöverskridningar) och aktivera sandbox-miljö genom underprocessisolering använder CLR-säkerhet begreppet verifiering.
Hanterade program kompileras till Microsoft Intermediate Language (MSIL). När metoder i ett hanterat program körs kompileras dess MSIL till intern kod via JIT-kompilering (Just-In-Time). JIT-kompilering innehåller en verifieringsprocess som tillämpar många säkerhets- och robusthetsregler som säkerställer att koden inte:
Bryta mot typkontrakt
Introducera buffertöverskridningar
Okontrollerad åtkomst till minne.
Hanterad kod som inte följer verifieringsreglerna får inte köras, såvida den inte anses vara betrodd kod.
Fördelen med verifierbar kod är en viktig orsak till att WPF bygger på .NET Framework. I den utsträckning som verifierbar kod används sänks möjligheten att utnyttja möjliga sårbarheter avsevärt.
Kodåtkomstsäkerhet
En klientdator exponerar en mängd olika resurser som ett hanterat program kan ha åtkomst till, inklusive filsystemet, registret, utskriftstjänster, användargränssnittet, reflektion och miljövariabler. Innan ett hanterat program kan komma åt någon av resurserna på en klientdator måste det ha .NET Framework-behörighet att göra det. En behörighet i CAS är en underklass av CodeAccessPermission; CAS implementerar en underklass för varje resurs som hanterade program kan komma åt.
Den uppsättning behörigheter som ett hanterat program beviljas av CAS när det börjar köras kallas för en behörighetsuppsättning och bestäms av bevis som tillhandahålls av programmet. För WPF-program är de bevis som tillhandahålls den plats eller zon som programmen startas från. CAS identifierar följande zoner:
Min dator. Program som startas från klientdatorn (fullständigt betrodda).
Lokalt intranät. Program som startas från intranätet. (Ganska betrodd)
Internet. Program som startas från Internet. (Minst betrodd).
Betrodda webbplatser. Program som identifieras av en användare som betrodda. (Minst betrodd).
Ej betrodda webbplatser. Program som identifieras av en användare som ej betrodda. (Ej betrodd).
För var och en av dessa zoner tillhandahåller CAS en fördefinierad behörighetsuppsättning som innehåller de behörigheter som matchar den förtroendenivå som är associerad med var och en. Dessa inkluderar:
FullTrust. För program som startas från zonen Min dator . Alla möjliga behörigheter beviljas.
LocalIntranet. För program som startas från zonen Lokalt intranät . En delmängd behörigheter beviljas för att ge måttlig åtkomst till en klientdators resurser, inklusive isolerad lagring, obegränsad användargränssnittsåtkomst, obegränsade fildialogrutor, begränsad reflektion, begränsad åtkomst till miljövariabler. Behörigheter för kritiska resurser som registret tillhandahålls inte.
Internet. För program som startas från zonen Internet eller Betrodda platser . En delmängd behörigheter beviljas för begränsad åtkomst till en klientdators resurser, inklusive isolerad lagring, endast filöppning och begränsat användargränssnitt. I princip isolerar den här behörighetsuppsättningen program från klientdatorn.
Program som identifieras som från zonen Ej betrodda platser beviljas inga behörigheter av CAS alls. Därför finns det ingen fördefinierad behörighetsuppsättning för dem.
Följande bild illustrerar relationen mellan zoner, behörighetsuppsättningar, behörigheter och resurser:
Begränsningarna för säkerhetssandlådan i zonen Internet gäller även för all kod som en XBAP importerar från ett systembibliotek, inklusive WPF. Detta säkerställer att varje bit av koden är låst, även WPF. Tyvärr, för att kunna köras behöver en XBAP utföra funktioner som kräver fler behörigheter än de som tillåts av säkerhetssandlådan i internetzonen.
Varning
XBAP:er kräver att äldre webbläsare används, till exempel Internet Explorer och gamla versioner av Firefox. Dessa äldre webbläsare stöds vanligtvis inte i Windows 10 och Windows 11. Moderna webbläsare stöder inte längre den teknik som krävs för XBAP-appar på grund av säkerhetsrisker. Plugin-program som aktiverar XBAP:er stöds inte längre. Mer information finns i Vanliga frågor och svar om WPF-webbläsarbaserade program (XBAP).
Överväg ett XBAP-program som innehåller följande sida:
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();
// Perform operation that uses the assert
// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
Om du vill köra den här XBAP:en måste den underliggande WPF-koden köra fler funktioner än vad som är tillgängligt för den anropande XBAP:en, inklusive:
Skapa ett fönsterhandtag (HWND) för återgivning
Skicka meddelanden
Läser in Tahoma-teckensnittet
Ur säkerhetssynpunkt skulle det vara katastrofalt att tillåta direkt åtkomst till någon av dessa åtgärder från det begränsade programmet.
Lyckligtvis tillgodoser WPF den här situationen genom att tillåta att dessa åtgärder körs med utökade privilegier för det sandbox-anpassade programmets räkning. Medan alla WPF-åtgärder kontrolleras mot de begränsade säkerhetsbehörigheterna i zonen Internet för programdomänen för XBAP, beviljas WPF (som med andra systembibliotek) en behörighetsuppsättning som innehåller alla möjliga behörigheter.
Detta kräver att WPF tar emot utökade privilegier samtidigt som behörigheterna inte styrs av behörighetsuppsättningen i zonen Internet för värdprogramdomänen.
WPF gör detta med hjälp av metoden Assert för en behörighet. Följande kod visar hur detta sker.
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();
// Perform operation that uses the assert
// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
Assert förhindrar i princip att de obegränsade behörigheter som krävs av WPF begränsas av XBAP:s Internetzonbehörigheter.
Från ett plattformsperspektiv ansvarar WPF för att använda Assert korrekt; en felaktig användning av Assert kan göra det möjligt för skadlig kod att höja behörigheterna. Därför är det viktigt att endast anropa Assert när det behövs och att se till att sandbox-begränsningarna förblir intakta. Till exempel tillåts inte kod i begränsat läge att öppna slumpmässiga filer, men det är tillåtet att använda teckensnitt. WPF gör det möjligt för sandbox-program att använda teckensnittsfunktioner genom att anropa Assert och att WPF läser filer som är kända för att innehålla dessa teckensnitt för det sandbox-programmets räkning.
ClickOnce-distribuering
ClickOnce är en omfattande distributionsteknik som ingår i .NET Framework och integreras med Visual Studio (se ClickOnce-säkerhet och distribution för detaljerad information). Fristående WPF-program kan distribueras med ClickOnce, medan webbläsarbaserade program måste distribueras med ClickOnce.
Program som distribueras med ClickOnce får ytterligare ett säkerhetslager över Code Access Security (CAS); I princip begär ClickOnce-distribuerade program de behörigheter som de behöver. De beviljas endast dessa behörigheter om de inte överskrider den uppsättning behörigheter för zonen som programmet distribueras från. Genom att minska behörighetsuppsättningen till endast de som behövs, även om de är mindre än de som tillhandahålls av startzonens behörighetsuppsättning, minskas antalet resurser som programmet har åtkomst till till ett minimum. Om programmet kapas minskar därför risken för skador på klientdatorn.
Security-Critical Metodik
WPF-koden som använder behörigheter för att aktivera sandbox-miljön i zonen Internet för XBAP-program måste hållas till högsta möjliga grad av säkerhetsgranskning och kontroll. För att underlätta detta krav ger .NET Framework nytt stöd för att hantera kod som höjer behörigheten. Mer specifikt gör CLR att du kan identifiera kod som höjer behörigheten och markera den med SecurityCriticalAttribute. All kod som inte är markerad med SecurityCriticalAttribute blir transparent med den här metoden. Omvänt förhindras hanterad kod som inte är markerad med SecurityCriticalAttribute från att höja behörigheten.
Varning
XBAP:er kräver att äldre webbläsare används, till exempel Internet Explorer och gamla versioner av Firefox. Dessa äldre webbläsare stöds vanligtvis inte i Windows 10 och Windows 11. Moderna webbläsare stöder inte längre den teknik som krävs för XBAP-appar på grund av säkerhetsrisker. Plugin-program som aktiverar XBAP:er stöds inte längre. Mer information finns i Vanliga frågor och svar om WPF-webbläsarbaserade program (XBAP).
Med Security-Critical-metoden kan du organisera WPF-kod som höjer behörigheten till säkerhetskritisk kernel, och resten är transparent. Genom att isolera den säkerhetskritiska koden kan WPF-teknikteamet fokusera ytterligare en säkerhetsanalys och källkontroll på den säkerhetskritiska kerneln utöver standardsäkerhetsmetoder (se WPF Security Strategy – Security Engineering).
Observera att .NET Framework tillåter betrodd kod för att utöka sandbox-miljön i XBAP-zonen i zonen Internet genom att tillåta utvecklare att skriva hanterade sammansättningar som är markerade med AllowPartiallyTrustedCallersAttribute (APTCA) och distribueras till användarens globala sammansättningscache (GAC). Att markera en sammansättning med APTCA är en mycket känslig säkerhetsåtgärd eftersom den tillåter all kod att anropa den sammansättningen, inklusive skadlig kod från Internet. Extrem försiktighet och metodtips måste användas när du gör detta och användarna måste välja att lita på programvaran för att den ska kunna installeras.
Microsoft Internet Explorer Security
Förutom att minska säkerhetsproblemen och förenkla säkerhetskonfigurationen innehåller Microsoft Internet Explorer 6 (SP2) flera funktioner som förbättrar säkerheten för användare av XAML-webbläsarprogram (XBAPs). Syftet med de här funktionerna är att ge användarna större kontroll över sin webbläsarupplevelse.
Varning
XBAP:er kräver att äldre webbläsare används, till exempel Internet Explorer och gamla versioner av Firefox. Dessa äldre webbläsare stöds vanligtvis inte i Windows 10 och Windows 11. Moderna webbläsare stöder inte längre den teknik som krävs för XBAP-appar på grund av säkerhetsrisker. Plugin-program som aktiverar XBAP:er stöds inte längre. Mer information finns i Vanliga frågor och svar om WPF-webbläsarbaserade program (XBAP).
Före IE6 SP2 kan användarna omfattas av något av följande:
Slumpmässiga popup-fönster.
Förvirrande omdirigering av skript.
Många säkerhetsdialogrutor på vissa webbplatser.
I vissa fall skulle opålitliga webbplatser försöka lura användare genom att förfalska användargränssnittet (UI) eller upprepade gånger visa en Microsoft ActiveX-installationsdialogruta, även om användaren kan ha avbrutit det. Med hjälp av dessa tekniker är det möjligt att ett stort antal användare har lurats att fatta dåliga beslut som resulterade i installation av spionprogram.
IE6 SP2 innehåller flera funktioner för att minimera dessa typer av problem, som kretsar kring begreppet användarinitiering. IE6 SP2 identifierar när en användare har klickat på ett länk- eller sidelement före en åtgärd, som kallas användarinitiering, och behandlar den annorlunda än när en liknande åtgärd i stället utlöses av skriptet på en sida. IE6 SP2 innehåller till exempel en Pop-Up Blocker som identifierar när en användare klickar på en knapp innan sidan skapar ett popup-fönster. Detta gör det möjligt för IE6 SP2 att tillåta de flesta harmlösa popup-fönster samtidigt som popup-fönster som användarna varken ber om eller vill ha. De blockerade pop-up-fönstren fångas upp av det nya informationsfältet, som låter användaren åsidosätta blockeringen manuellt och visa pop-up-fönstret.
Samma logik för initiering av användare tillämpas också på öppna/spara säkerhetsprompter. Dialogrutor för ActiveX-installation är alltid fångade under informationsfältet om de inte representerar en uppgradering från en tidigare installerad kontroll. Dessa åtgärder kombineras för att ge användarna en säkrare och mer kontrollerad användarupplevelse eftersom de skyddas mot webbplatser som trakasserar dem att installera oönskad eller skadlig programvara.
Dessa funktioner skyddar även kunder som använder IE6 SP2 för att bläddra till webbplatser där de kan ladda ned och installera WPF-program. I synnerhet beror det på att IE6 SP2 erbjuder en bättre användarupplevelse som minskar risken för användare att installera skadliga eller bedrägliga program oavsett vilken teknik som användes för att bygga den, inklusive WPF. WPF lägger till dessa skydd med hjälp av ClickOnce för att underlätta nedladdningen av dess program via Internet. Eftersom XAML-webbläsarprogram (XBAPs) körs i en sandbox-miljö för säkerhet i zonen Internet kan de startas sömlöst. Å andra sidan kräver fristående WPF-program fullständigt förtroende för att köras. För dessa program visar ClickOnce en säkerhetsdialogruta under startprocessen för att meddela användningen av programmets ytterligare säkerhetskrav. Detta måste dock vara användarinitierat, kommer också att styras av användarinitierad logik och kan avbrytas.
Internet Explorer 7 införlivar och utökar säkerhetsfunktionerna i IE6 SP2 som en del av ett pågående säkerhetsåtagande.
Se även
.NET Desktop feedback