Dela via

Säkerhetsöverväganden för XAML

  • Artikel

I den här artikeln beskrivs metodtips för säkerhet i program när du använder XAML- och .NET XAML Services API.

Ej betrodd XAML i program

I den mest allmänna bemärkelsen är ej betrodd XAML en XAML-källa som programmet inte specifikt inkluderade eller avgav.

XAML som kompileras till eller lagras som en resx-type-resurs i en betrodd och signerad sammansättning är inte i sig obetrodd. Du kan lita på XAML lika mycket som du litar på sammansättningen som helhet. I de flesta fall bryr du dig bara om förtroendeaspekterna för lös XAML, som är en XAML-källa som du läser in från en ström eller annan I/O. Lös XAML är inte en specifik komponent eller funktion i en programmodell med en distributions- och paketeringsinfrastruktur. En sammansättning kan dock implementera ett beteende som innebär att lösa XAML läses in.

För obetrodd XAML bör du behandla den i allmänhet på samma sätt som om den inte var betrodd kod. Använd sandbox-miljö eller andra metaforer för att förhindra att eventuellt ej betrodd XAML kommer åt din betrodda kod.

XAML-funktionerna ger XAML rätt att konstruera objekt och ange deras egenskaper. Dessa funktioner omfattar även åtkomst till typkonverterare, mappning och åtkomst till sammansättningar i programdomänen, användning av tillägg för markering, x:Code block och så vidare.

Utöver dess funktioner på språknivå används XAML för användargränssnittsdefinition i många tekniker. Inläsning av ej betrodd XAML kan innebära att ett skadligt förfalskningsgränssnitt läses in.

Dela kontext mellan läsare och författare

.NET XAML Services-arkitektur för XAML-läsare och XAML-skrivare kräver ofta att en XAML-läsare delas med en XAML-skrivare eller en delad XAML-schemakontext. Delning av objekt eller kontexter kan krävas om du skriver XAML-nodlooplogik eller tillhandahåller en anpassad sökväg för sparande. Dela inte XAML-läsarinstanser, nondefault XAML-schemakontext eller inställningar för XAML-läsar-/skrivklasser mellan betrodd och ej betrodd kod.

De flesta scenarier och åtgärder som involverar XAML-objekt som skriver för en CLR-baserad typstöd kan bara använda standard-XAML-schemakontext. Standard-XAML-schemakontexten innehåller inte uttryckligen inställningar som kan äventyra fullständigt förtroende. Det är därför säkert att dela kontext mellan betrodda och ej betrodda XAML-läsare/skrivarkomponenter. Men om du gör detta är det fortfarande en bra idé att hålla sådana läsare och författare i separata AppDomain omfång, med en av dem specifikt avsedd/begränsat för partiellt förtroende.

XAML-namnområden och sammansättningsförtroende

Den grundläggande okvalificerade syntaxen och definitionen för hur XAML tolkar en anpassad XAML-namnområdesmappning till en sammansättning skiljer inte mellan en betrodd och ej betrodd sammansättning som läses in i programdomänen. Det är därför tekniskt möjligt för en ej betrodd sammansättning att förfalska en betrodd sammansättnings avsedda XAML-namnområdesmappning och avbilda en XAML-källas deklarerade objekt- och egenskapsinformation. Om du har säkerhetskrav för att undvika den här situationen bör din avsedda XAML-namnområdesmappning göras med någon av följande tekniker:

  • Använd ett fullständigt kvalificerat sammansättningsnamn med starkt namn i alla XAML-namnområdesmappningar som görs av ditt programs XAML.

  • Begränsa sammansättningsmappning till en fast uppsättning referenssammansättningar genom att skapa en specifik XamlSchemaContext för XAML-läsare och XAML-objektskrivare. Se XamlSchemaContext(IEnumerable<Assembly>).

XAML-typmappning och typsystemåtkomst

XAML stöder sitt eget typsystem, som på många sätt är en peer-fil till hur CLR implementerar det grundläggande CLR-typsystemet. För vissa aspekter av typmedvetenhet där du fattar förtroendebeslut om en typ baserat på dess typinformation bör du dock skjuta upp typinformationen i CLR-säkerhetskopieringstyperna. Detta beror på att vissa av de specifika rapporteringsfunktionerna i XAML-typsystemet lämnas öppna som virtuella metoder och därför inte är helt under kontroll av de ursprungliga .NET XAML Services-implementeringarna. Dessa utökningspunkter finns eftersom XAML-typsystemet är utökningsbart, för att matcha utökningsbarheten för själva XAML och dess möjliga alternativa typmappningsstrategier jämfört med standard clr-backad implementering och standard XAML-schemakontext. Mer information finns i de specifika anteckningarna om flera av egenskaperna för XamlType och XamlMember.

Se även