Zagadnienia dotyczące zabezpieczeń XAML

  • Artykuł

W tym artykule opisano najlepsze rozwiązania dotyczące zabezpieczeń w aplikacjach podczas korzystania z interfejsu API usług XAML i .NET XAML.

Niezaufany kod XAML w aplikacjach

W najbardziej ogólnym sensie niezaufany kod XAML to dowolne źródło XAML, którego aplikacja nie zawierała ani nie emitowała.

Kod XAML kompilowany lub przechowywany jako resxzasób typu w zaufanym i podpisanym zestawie nie jest z natury niezaufany. Możesz ufać XAML tak samo, jak ufasz zestawowi jako całości. W większości przypadków dotyczy to tylko aspektów zaufania luźnego kodu XAML, które jest źródłem XAML ładowanym ze strumienia lub innych operacji 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 zaimplementować zachowanie, które obejmuje ładowanie luźnego kodu XAML.

W przypadku niezaufanego kodu XAML należy traktować go ogólnie tak samo, jak w przypadku niezaufanego kodu. Użyj piaskownicy lub innych metafor, aby zapobiec prawdopodobnie niezaufanej kodzie XAML uzyskiwania dostępu do zaufanego kodu.

Charakter możliwości XAML daje XAML prawo do konstruowania obiektów i ustawiania 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 itd.

Oprócz możliwości na poziomie języka język XAML jest używany do definicji interfejsu użytkownika w wielu technologiach. Ładowanie niezaufanego kodu XAML może oznaczać ładowanie złośliwego interfejsu użytkownika fałszowania.

Udostępnianie kontekstu między czytelnikami i pisarzami

Architektura usług XAML platformy .NET dla czytników XAML i składników zapisywania XAML często wymaga udostępniania czytnika XAML do składnika zapisywania XAML lub udostępnionego 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 udostępniaj wystąpień czytnika XAML, niezdefiniowanego kontekstu schematu XAML ani ustawień dla klas czytnika/zapisywania XAML między zaufanym i niezaufanym kodem.

Większość scenariuszy i operacji obejmujących zapisywanie obiektów XAML dla kopii zapasowej typu opartego na 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. Dzięki temu można bezpiecznie współużytkować kontekst między zaufanymi i niezaufanym składnikiem czytnika/modułu zapisywania XAML. Jeśli jednak to zrobisz, nadal najlepszym rozwiązaniem jest zachowanie takich czytelników i autorów w osobnych AppDomain zakresach, z jednym z nich przeznaczonym/w trybie piaskownicy dla częściowego zaufania.

Przestrzenie nazw XAML i zaufanie zestawów

Podstawowa niekwalifikowana składnia i definicja sposobu interpretowania niestandardowego mapowania przestrzeni nazw XAML na zestaw nie rozróżnia zaufanego i niezaufanego zestawu jako załadowanego do domeny aplikacji. W związku z tym technicznie istnieje możliwość fałszowania zamierzonego mapowania przestrzeni nazw XAML zaufanego zestawu i przechwytywania zadeklarowanego obiektu i informacji o właściwościach źródła XAML. Jeśli masz wymagania dotyczące zabezpieczeń, aby uniknąć tej sytuacji, zamierzone mapowanie przestrzeni nazw XAML powinno zostać wykonane przy użyciu jednej z następujących technik:

  • Użyj w pełni kwalifikowanej nazwy zestawu o silnej nazwie w dowolnym mapowaniu przestrzeni nazw XAML utworzonego przez kod XAML aplikacji.

  • Ogranicz mapowanie zestawów do stałego zestawu odwołań, tworząc element specyficzny XamlSchemaContext dla czytników XAML i składników zapisywania 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 elementem równorzędnym, w jaki sposób CLR implementuje podstawowy system typów 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 typów kopii zapasowych CLR. Wynika to z faktu, że niektóre z określonych możliwości raportowania systemu typów XAML pozostają 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, aby dopasować rozszerzalność samego kodu XAML i jego możliwe alternatywne strategie mapowania typów w porównaniu z domyślną implementacją i domyślnym kontekstem schematu XAML opartym na clR. Aby uzyskać więcej informacji, zobacz konkretne uwagi dotyczące kilku właściwości i XamlTypeXamlMember.

Zobacz też