Zagadnienia dotyczące zabezpieczeń XAML
W tym artykule opisano najlepsze rozwiązania dotyczące zabezpieczeń w aplikacjach w przypadku korzystania z interfejsu API usług XAML i .NET XAML.
Niezaufany kod XAML w aplikacjach
Ogólnie rzecz biorąc, niezaufany kod XAML to dowolne źródło XAML, które nie było w szczególności dołączane ani emitowane przez aplikację.
Xaml, który jest kompilowany do lub przechowywany jako resxzasób typu w zaufanym i podpisanym zestawie, nie jest z założenia niezaufany. Możesz ufać językowi XAML tak samo jak całemu zestawowi. W większości przypadków chodzi tylko o aspekty zaufania luźnego kodu XAML, który jest źródłem XAML ładowany ze strumienia lub innych we/wy. Luźny kod XAML nie jest określonym składnikiem ani funkcją modelu aplikacji z infrastrukturą wdrażania i pakowania. Jednak zestaw może implementować zachowanie, które obejmuje ładowanie luźnego kodu XAML.
W przypadku niezaufanego kodu XAML należy traktować go ogólnie tak samo, jakby był niezaufany kod. Użyj piaskownicy lub innych metafor, aby zapobiec dostępowi do zaufanego kodu za pomocą potencjalnie niezaufanego kodu XAML.
Charakter możliwości XAML daje XAML prawo do konstruowania obiektów i ustawianie ich właściwości. Te możliwości obejmują również uzyskiwanie dostępu do konwerterów typów, mapowanie i uzyskiwanie dostępu do zestawów w domenie aplikacji przy użyciu rozszerzeń znaczników, x:Code bloków i tak dalej.
Oprócz możliwości na poziomie języka język XAML jest używany do definiowania interfejsu użytkownika w wielu technologiach. Ładowanie niezaufanego kodu XAML może oznaczać załadowanie złośliwego interfejsu użytkownika do fałszowania.
Udostępnianie kontekstu między czytelnikami i autorami
Architektura usług XAML .NET dla czytników XAML i autorów XAML często wymaga udostępnienia czytnika XAML autorowi kodu XAML lub współdzieloneowi kontekstu schematu XAML. Udostępnianie obiektów lub kontekstów może być wymagane, jeśli piszesz logikę pętli węzłów XAML lub udostępniasz niestandardową ścieżkę zapisywania. Nie należy udostępniać wystąpień czytnika XAML, niedefaultnego kontekstu schematu XAML ani ustawień dla klas czytnika/zapisu XAML między zaufanym i niezaufanym kodem.
Większość scenariuszy i operacji związanych z zapisywaniem obiektów XAML dla kopii zapasowej typu opartego na języku CLR może po prostu używać domyślnego kontekstu schematu XAML. Domyślny kontekst schematu XAML nie zawiera jawnie ustawień, które mogą naruszyć pełne zaufanie. W związku z tym można bezpiecznie udostępniać kontekst między zaufanymi i niezaufanymi składnikami czytnika/składników zapisujący XAML. Jeśli jednak to zrobisz, AppDomain nadal najlepszym rozwiązaniem jest zachowanie takich czytników i autorów w oddzielnych zakresach, przy których jeden z nich jest specjalnie przeznaczony/w trybie piaskownicy w celu częściowego zaufania.
Przestrzenie nazw XAML i zaufanie do zestawu
Podstawowa niekwalifikowana składnia i definicja sposobu, w jaki język XAML interpretuje mapowanie niestandardowej przestrzeni nazw XAML do zestawu, nie rozróżnia zaufanego i niezaufanego zestawu ładowanego do domeny aplikacji. W związku z tym technicznie jest możliwe, aby niezaufany zestaw podszył się pod zamierzone mapowanie przestrzeni nazw XAML zaufanego zestawu i przechwycił zadeklarowany obiekt i informacje o właściwościach źródła XAML. Jeśli masz wymagania dotyczące zabezpieczeń, aby tego uniknąć, mapowanie zamierzonych przestrzeni nazw XAML powinno zostać wykonane przy użyciu jednej z następujących technik:
Użyj w pełni kwalifikowanej nazwy zestawu z silną nazwą w dowolnym mapowaniu przestrzeni nazw XAML wykonanym przez kod XAML aplikacji.
Ogranicz mapowanie zestawów do stałego zestawu zestawów odwoływczych, XamlSchemaContext konstruując specyficzny dla czytników XAML i autorów obiektów XAML. Zobacz: XamlSchemaContext(IEnumerable<Assembly>).
Mapowanie typów XAML i dostęp do systemu typów
Język XAML obsługuje własny system typów, który na wiele sposobów jest równorzędny do sposobu implementowania podstawowego systemu typów CLR przez clr. Jednak w przypadku niektórych aspektów świadomości typów, w których podejmujesz decyzje dotyczące zaufania dotyczące typu na podstawie informacji o typie, należy odroczyć informacje o typie w typach bazowych CLR. Wynika to z tego, że niektóre funkcje raportowania systemu typów XAML są otwarte jako metody wirtualne i dlatego nie są w pełni pod kontrolą oryginalnych implementacji usług XAML platformy .NET. Te punkty rozszerzalności istnieją, ponieważ system typów XAML jest rozszerzalny w celu dopasowania do rozszerzalności samego xamlu i jego możliwych alternatywnych strategii mapowania typów w porównaniu z domyślną implementacją i domyślnym kontekstem schematu XAML. Aby uzyskać więcej informacji, zobacz uwagi dotyczące kilku właściwości i XamlTypeXamlMember.