Delen via

Beveiligingsoverwegingen voor XAML

  • Artikel

In dit artikel worden aanbevolen procedures voor beveiliging in toepassingen beschreven wanneer u de XAML- en .NET XAML Services-API gebruikt.

Niet-vertrouwde XAML in toepassingen

In de meest algemene zin is niet-vertrouwde XAML een XAML-bron die uw toepassing niet specifiek heeft opgenomen of verzonden.

XAML die is gecompileerd in of opgeslagen als een resx-type resource binnen een vertrouwde en ondertekende assembly is niet inherent niet vertrouwd. U kunt de XAML zoveel vertrouwen als u de assembly als geheel vertrouwt. In de meeste gevallen hebt u alleen betrekking op de vertrouwensaspecten van losse XAML, een XAML-bron die u laadt vanuit een stroom of andere I/O. Losjes XAML is geen specifiek onderdeel of onderdeel van een toepassingsmodel met een implementatie- en verpakkingsinfrastructuur. Een assembly kan echter een gedrag implementeren dat betrekking heeft op het laden van losse XAML.

Voor niet-vertrouwde XAML moet u deze over het algemeen hetzelfde behandelen als als niet-vertrouwde code. Gebruik sandboxing of andere metaforen om te voorkomen dat mogelijk niet-vertrouwde XAML toegang heeft tot uw vertrouwde code.

De aard van de XAML-mogelijkheden geeft de XAML het recht om objecten te maken en hun eigenschappen in te stellen. Deze mogelijkheden omvatten ook toegang tot typeconversieprogramma's, toewijzing en toegang tot assembly's in het toepassingsdomein, met behulp van markeringsextensies, x:Code blokken, enzovoort.

Naast de mogelijkheden op taalniveau wordt XAML in veel technologieën gebruikt voor de definitie van de gebruikersinterface. Het laden van niet-vertrouwde XAML kan betekenen dat een schadelijke spoofing-gebruikersinterface wordt geladen.

Context delen tussen lezers en schrijvers

.NET XAML Services-architectuur voor XAML-lezers en XAML-schrijvers vereist vaak het delen van een XAML-lezer voor een XAML-schrijver of een gedeelde XAML-schemacontext. Het delen van objecten of contexten is mogelijk vereist als u XAML-knooppuntluslogica schrijft of een aangepast opslagpad opgeeft. Deel geen XAML-lezerexemplaren, niet-standaard XAML-schemacontext of instellingen voor XAML-lezer-/schrijverklassen tussen vertrouwde en niet-vertrouwde code.

De meeste scenario's en bewerkingen met betrekking tot het schrijven van XAML-objecten voor een clr-gebaseerde typebacking kunnen gewoon gebruikmaken van de standaard XAML-schemacontext. De standaardcontext van het XAML-schema bevat niet expliciet instellingen die een volledige vertrouwensrelatie kunnen in gevaar komen. Het is dus veilig om context te delen tussen vertrouwde en niet-vertrouwde XAML-lezer-/schrijveronderdelen. Als u dit echter doet, is het nog steeds een best practice om dergelijke lezers en schrijvers gescheiden AppDomain bereiken te houden, met een van hen specifiek bedoeld/sandboxed voor gedeeltelijke vertrouwen.

XAML-naamruimten en assemblyvertrouwensrelatie

De niet-gekwalificeerde basissyntaxis en -definitie voor hoe XAML een aangepaste XAML-naamruimtetoewijzing aan een assembly interpreteert, maakt geen onderscheid tussen een vertrouwde en niet-vertrouwde assembly die in het toepassingsdomein wordt geladen. Het is dus technisch mogelijk voor een niet-vertrouwde assembly om de beoogde XAML-naamruimtetoewijzing van een vertrouwde assembly te spoofen en de gedeclareerde object- en eigenschapsgegevens van een XAML-bron vast te leggen. Als u beveiligingsvereisten hebt om deze situatie te voorkomen, moet de beoogde XAML-naamruimtetoewijzing worden gemaakt met behulp van een van de volgende technieken:

  • Gebruik een volledig gekwalificeerde assemblynaam met een sterke naam in elke XAML-naamruimtetoewijzing die is gemaakt door de XAML van uw toepassing.

  • Beperk assemblytoewijzing tot een vaste set referentieassembly's door een specifieke XamlSchemaContext te maken voor uw XAML-lezers en XAML-objectschrijvers. Zie XamlSchemaContext(IEnumerable<Assembly>).

XAML-typetoewijzing en systeemtoegang

XAML ondersteunt een eigen typesysteem, dat op veel manieren een peer is van de manier waarop CLR het basis-CLR-typesysteem implementeert. Voor bepaalde aspecten van het type bewustzijn waarbij u echter vertrouwensbeslissingen neemt over een type op basis van de typegegevens, moet u de typegegevens in de clr-backingtypen uitstellen. Dit komt doordat sommige van de specifieke rapportagemogelijkheden van het XAML-typesysteem open blijven als virtuele methoden en daarom niet volledig onder het beheer van de oorspronkelijke .NET XAML Services-implementaties vallen. Deze uitbreidbaarheidspunten bestaan omdat het XAML-typesysteem uitbreidbaar is, zodat deze overeenkomt met de uitbreidbaarheid van XAML zelf en de mogelijke alternatieve strategieën voor typetoewijzing versus de standaard-CLR-implementatie en de standaardcontext van het XAML-schema. Zie de specifieke opmerkingen over verschillende eigenschappen van XamlType en XamlMembervoor meer informatie.

Zie ook