Problemy związane z zabezpieczeniami w emisji odbicia

Program .NET Framework udostępnia trzy sposoby emitowania wspólnego języka pośredniego (CIL), z których każdy ma własne problemy z zabezpieczeniami:

Niezależnie od sposobu generowania kodu dynamicznego wykonywanie wygenerowanego kodu wymaga wszystkich uprawnień wymaganych przez typy i metody, których używa wygenerowany kod.

Uwaga

Uprawnienia wymagane do odzwierciedlenia kodu i emitowania kodu uległy zmianie wraz z pomyślnymi wersjami programu .NET Framework. Zobacz Informacje o wersji w dalszej części tego artykułu.

Zestawy dynamiczne

Zestawy dynamiczne są tworzone przy użyciu przeciążeń AppDomain.DefineDynamicAssembly metody . Większość przeciążeń tej metody jest przestarzała w programie .NET Framework 4 ze względu na eliminację zasad zabezpieczeń dla całej maszyny. Pozostałe przeciążenia mogą być wykonywane przez dowolny kod, niezależnie od poziomu zaufania. Te przeciążenia dzielą się na dwie grupy: te, które określają listę atrybutów, które mają być stosowane do zestawu dynamicznego podczas jego tworzenia, i tych, które nie. Jeśli nie określisz modelu przezroczystości dla zestawu, stosując SecurityRulesAttribute atrybut podczas jego tworzenia, model przezroczystości jest dziedziczony z emitowanego zestawu.

Uwaga

Atrybuty stosowane do zestawu dynamicznego po jego utworzeniu przy użyciu SetCustomAttribute metody nie obowiązują, dopóki zestaw nie zostanie zapisany na dysku i ponownie załadowany do pamięci.

Kod w zestawie dynamicznym może uzyskiwać dostęp do widocznych typów i elementów członkowskich w innych zestawach.

Uwaga

Zestawy dynamiczne nie używają ReflectionPermissionFlag.MemberAccess flag i ReflectionPermissionFlag.RestrictedMemberAccess , które umożliwiają dynamicznym metodom uzyskiwania dostępu do typów niepublickich i elementów członkowskich.

Przejściowe zestawy dynamiczne są tworzone w pamięci i nigdy nie są zapisywane na dysku, dlatego nie wymagają uprawnień dostępu do plików. Zapisanie zestawu dynamicznego na dysku wymaga FileIOPermission użycia odpowiednich flag.

Generowanie zestawów dynamicznych na podstawie częściowo zaufanego kodu

Rozważ warunki, w których zestaw z uprawnieniami do Internetu może wygenerować przejściowy zestaw dynamiczny i wykonać jego kod:

  • Zestaw dynamiczny używa tylko typów publicznych i elementów członkowskich innych zestawów.

  • Uprawnienia wymagane przez te typy i elementy członkowskie są uwzględniane w zestawie dotacji częściowo zaufanego zestawu.

  • Zestaw nie jest zapisywany na dysku.

  • Symbole debugowania nie są generowane. (Internet i LocalIntranet zestawy uprawnień nie zawierają niezbędnych uprawnień).

Metody dynamiczne hostowane anonimowo

Metody dynamiczne hostowane anonimowo są tworzone przy użyciu dwóch DynamicMethod konstruktorów, które nie określają skojarzonego typu lub modułu, DynamicMethod(String, Type, Type[]) i DynamicMethod(String, Type, Type[], Boolean). Te konstruktory umieszczają metody dynamiczne w zestawie udostępnionym przez system, w pełni zaufanym, przezroczystym pod względem zabezpieczeń. Do używania tych konstruktorów ani do emitowania kodu dla metod dynamicznych nie są wymagane żadne uprawnienia.

Zamiast tego po utworzeniu anonimowej hostowanej metody dynamicznej stos wywołań jest przechwytywany. Po utworzeniu metody wymagania dotyczące zabezpieczeń są wykonywane względem przechwyconego stosu wywołań.

Uwaga

Koncepcyjnie wymagania są wykonywane podczas budowy metody. Oznacza to, że żądania mogą być wykonywane, ponieważ każda instrukcja CIL jest emitowana. W bieżącej implementacji wszystkie wymagania są wykonywane, gdy DynamicMethod.CreateDelegate metoda jest wywoływana lub gdy kompilator just in time (JIT) jest wywoływany, jeśli metoda jest wywoływana bez wywołania metody CreateDelegate.

Jeśli domena aplikacji zezwala na to, anonimowo hostowane metody dynamiczne mogą pominąć kontrole widoczności JIT, z zastrzeżeniem następującego ograniczenia: Typy niepublicowe i elementy członkowskie dostępne przez anonimowo hostowaną metodę dynamiczną muszą znajdować się w zestawach, których zestawy przyznawania są równe lub podzbioru zestawu dotacji stosu emitowania wywołań. Ta ograniczona możliwość pomijania sprawdzania widoczności trybu JIT jest włączona, jeśli domena aplikacji przyznaje ReflectionPermission flagę ReflectionPermissionFlag.RestrictedMemberAccess .

  • Jeśli metoda używa tylko typów publicznych i elementów członkowskich, żadne uprawnienia nie są wymagane podczas budowy.

  • Jeśli określisz, że kontrole widoczności trybu JIT powinny zostać pominięte, żądanie, które jest wykonywane podczas konstruowania metody zawiera ReflectionPermission flagę ReflectionPermissionFlag.RestrictedMemberAccess i zestaw dotacji zestawu, który zawiera niepublikowany element członkowski, do którego uzyskuje się dostęp.

Ze względu na to, że zestaw dotacji niepublikowego elementu członkowskiego jest brany pod uwagę, częściowo zaufany kod, któremu udzielono ReflectionPermissionFlag.RestrictedMemberAccess uprawnień, nie może podnieść jego uprawnień, wykonując niepublikowane elementy członkowskie zaufanych zestawów.

Podobnie jak w przypadku dowolnego innego emitowanego kodu, wykonanie metody dynamicznej wymaga od metod, których używa metoda dynamiczna.

Zestaw systemowy hostujący anonimowe metody dynamiczne korzysta z SecurityRuleSet.Level1 modelu przezroczystości, który jest modelem przezroczystości używanym w programie .NET Framework przed programem .NET Framework 4.

Aby uzyskać więcej informacji, zobacz klasę DynamicMethod .

Generowanie anonimowo hostowanych metod dynamicznych na podstawie częściowo zaufanego kodu

Rozważ warunki, w których zestaw z uprawnieniami do Internetu może wygenerować anonimowo hostowaną metodę dynamiczną i wykonać ją:

  • Metoda dynamiczna używa tylko typów publicznych i elementów członkowskich. Jeśli zestaw dotacji zawiera ReflectionPermissionFlag.RestrictedMemberAccesselement , może używać typów niepublicowych i elementów członkowskich dowolnego zestawu, którego zestaw dotacji jest równy lub podzbiór zestawu przyznawania.

  • Uprawnienia wymagane przez wszystkie typy i elementy członkowskie używane przez metodę dynamiczną są uwzględniane w zestawie dotacji częściowo zaufanego zestawu.

Uwaga

Metody dynamiczne nie obsługują symboli debugowania.

Metody dynamiczne skojarzone z istniejącymi zestawami

Aby skojarzyć metodę dynamiczną z typem lub modułem w istniejącym zestawie, użyj dowolnego DynamicMethod konstruktora, który określa skojarzony typ lub moduł. Uprawnienia wymagane do wywołania tych konstruktorów różnią się, ponieważ kojarzenie metody dynamicznej z istniejącym typem lub modułem zapewnia dynamiczny dostęp metody do typów niepublikacyjnych i elementów członkowskich:

  • Metoda dynamiczna skojarzona z typem ma dostęp do wszystkich elementów członkowskich tego typu, nawet prywatnych elementów członkowskich oraz do wszystkich typów wewnętrznych i składowych w zestawie zawierającym skojarzony typ.

  • Metoda dynamiczna skojarzona z modułem ma dostęp do wszystkich internal typów i elementów członkowskich (Friend w języku Visual Basic assembly w metadanych środowiska uruchomieniowego języka wspólnego) w module.

Ponadto można użyć konstruktora, który określa możliwość pomijania kontroli widoczności kompilatora JIT. Dzięki temu metoda dynamiczna ma dostęp do wszystkich typów i elementów członkowskich we wszystkich zestawach, niezależnie od poziomu dostępu.

Uprawnienia wymagane przez konstruktora zależą od tego, ile dostępu decydujesz się na nadanie metodzie dynamicznej:

Chociaż elementy na tej liście są opisane pod względem zestawu dotacji emitowanego zestawu, należy pamiętać, że wymagania są wykonywane względem pełnego stosu wywołań, w tym granicy domeny aplikacji.

Aby uzyskać więcej informacji, zobacz klasę DynamicMethod .

Generowanie metod dynamicznych na podstawie częściowo zaufanego kodu

Uwaga

Zalecanym sposobem generowania metod dynamicznych z częściowo zaufanego kodu jest użycie metod dynamicznych hostowanych anonimowo.

Rozważ warunki, w których zestaw z uprawnieniami do Internetu może wygenerować metodę dynamiczną i wykonać ją:

  • Metoda dynamiczna jest skojarzona z modułem lub typem, który go emituje, albo zestaw grantów zawiera ReflectionPermissionFlag.RestrictedMemberAccess i jest skojarzony z modułem w zestawie, którego zestaw grantów jest równy lub podzestawu grantu zestawu emitowania.

  • Metoda dynamiczna używa tylko typów publicznych i elementów członkowskich. Jeśli jego zestaw dotacji zawiera ReflectionPermissionFlag.RestrictedMemberAccess i jest skojarzony z modułem w zestawie, którego zestaw dotacji jest równy lub podzbiór zestawu przyznawania, może używać typów i elementów członkowskich oznaczonych internal (Friend w Visual Basic, assembly w metadanych środowiska uruchomieniowego języka wspólnego) w skojarzonym module.

  • Uprawnienia wymagane przez wszystkie typy i elementy członkowskie używane przez metodę dynamiczną są uwzględniane w zestawie dotacji częściowo zaufanego zestawu.

  • Metoda dynamiczna nie pomija kontroli widoczności JIT.

Uwaga

Metody dynamiczne nie obsługują symboli debugowania.

Informacje o wersji

Począwszy od programu .NET Framework 4, zasady zabezpieczeń dla całej maszyny są usuwane, a przejrzystość zabezpieczeń staje się domyślnym mechanizmem wymuszania.

Począwszy od programu .NET Framework 2.0 z dodatkiem Service Pack 1, ReflectionPermission flaga ReflectionPermissionFlag.ReflectionEmit nie jest już wymagana podczas emitowania zestawów dynamicznych i metod dynamicznych. Ta flaga jest wymagana we wszystkich wcześniejszych wersjach programu .NET Framework.

Uwaga

ReflectionPermission z flagą ReflectionPermissionFlag.ReflectionEmit jest domyślnie dołączana do FullTrust zestawów uprawnień i LocalIntranet nazwanych, ale nie w Internet zestawie uprawnień. W związku z tym we wcześniejszych wersjach programu .NET Framework biblioteka może być używana z uprawnieniami do Internetu tylko wtedy, gdy wykonuje element Assert dla ReflectionEmitprogramu . Takie biblioteki wymagają dokładnego przeglądu zabezpieczeń, ponieważ błędy kodowania mogą powodować luki w zabezpieczeniach. Program .NET Framework 2.0 z dodatkiem SP1 umożliwia emitowanie kodu w scenariuszach częściowego zaufania bez wystawiania żadnych wymagań dotyczących zabezpieczeń, ponieważ generowanie kodu nie jest z natury operacją uprzywilejowaną. Oznacza to, że wygenerowany kod nie ma więcej uprawnień niż zestaw, który go emituje. Dzięki temu biblioteki emitujące kod mogą być przezroczyste w zabezpieczeniach i eliminuje potrzebę potwierdzenia ReflectionEmit, co upraszcza zadanie pisania bezpiecznej biblioteki.

Ponadto program .NET Framework 2.0 z dodatkiem SP1 wprowadza flagę ReflectionPermissionFlag.RestrictedMemberAccess uzyskiwania dostępu do typów niepublicowych i elementów członkowskich z częściowo zaufanych metod dynamicznych. Wcześniejsze wersje programu .NET Framework wymagają ReflectionPermissionFlag.MemberAccess flagi dla metod dynamicznych, które uzyskują dostęp do typów niepublistycznych i elementów członkowskich. Jest to uprawnienie, które nigdy nie powinno być przyznawane częściowo zaufanemu kodzie.

Na koniec program .NET Framework 2.0 z dodatkiem SP1 wprowadza anonimowe metody hostowane.

Uzyskiwanie informacji o typach i elementach członkowskich

Począwszy od programu .NET Framework 2.0, żadne uprawnienia nie są wymagane do uzyskania informacji o typach niepublikacyjnych i elementach członkowskich. Emocje ion służy do uzyskiwania informacji potrzebnych do emitowania metod dynamicznych. Na przykład MethodInfo obiekty są używane do emitowania wywołań metod. Wcześniejsze wersje programu .NET Framework wymagają ReflectionPermission flagi ReflectionPermissionFlag.TypeInformation . Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące zabezpieczeń dla Emocje ion.

Zobacz też