Zagadnienia dotyczące zabezpieczeń dla odbicia

  • Artykuł

Emocje ion zapewnia możliwość uzyskiwania informacji o typach i elementach członkowskich oraz uzyskiwania dostępu do elementów członkowskich (czyli wywoływania metod i konstruktorów, pobierania i ustawiania wartości właściwości, dodawania i usuwania programów obsługi zdarzeń itd.). Użycie odbicia w celu uzyskania informacji o typach i elementach członkowskich nie jest ograniczone. Cały kod może używać odbicia do wykonywania następujących zadań:

  • Wyliczanie typów i elementów członkowskich oraz sprawdzanie ich metadanych.
  • Wyliczanie i badanie zestawów i modułów.

Natomiast użycie odbicia w celu uzyskania dostępu do członków podlega ograniczeniom. Począwszy od programu .NET Framework 4, tylko zaufany kod może używać odbicia w celu uzyskania dostępu do elementów członkowskich o krytycznym znaczeniu dla zabezpieczeń. Ponadto tylko zaufany kod może używać odbicia w celu uzyskania dostępu do niepublikowanych elementów członkowskich, które nie byłyby bezpośrednio dostępne dla skompilowanego kodu. Na koniec kod, który używa odbicia w celu uzyskania dostępu do elementu członkowskiego o znaczeniu krytycznym, musi mieć jakiekolwiek uprawnienia wymagane przez element członkowski o znaczeniu krytycznym, podobnie jak w przypadku skompilowanego kodu.

Z zastrzeżeniem niezbędnych uprawnień kod może używać odbicia w celu wykonania następujących rodzajów dostępu:

  • Uzyskaj dostęp do publicznych członków, którzy nie mają krytycznego zabezpieczeń.

  • Uzyskaj dostęp do niepublikowanych elementów członkowskich, które byłyby dostępne dla skompilowanego kodu, jeśli te elementy członkowskie nie są krytyczne dla zabezpieczeń. Przykłady takich niepublicowych elementów członkowskich to:

    • Chronione elementy członkowskie klas bazowych kodu wywołującego. (W odbiciu jest to nazywane dostępem na poziomie rodziny).

    • internal elementy członkowskie (Friend elementy członkowskie w visual basic) w zestawie kodu wywołującego. (W odbiciu jest to nazywane dostępem na poziomie zestawu).

    • Prywatne elementy członkowskie innych wystąpień klasy zawierającej kod wywołujący.

Na przykład kod uruchamiany w domenie aplikacji w trybie piaskownicy jest ograniczony do dostępu opisanego na tej liście, chyba że domena aplikacji udziela dodatkowych uprawnień.

Począwszy od programu .NET Framework 2.0 z dodatkiem Service Pack 1, próba uzyskania dostępu do elementów członkowskich, które są zwykle niedostępne, generuje żądanie dla zestawu dotacji obiektu docelowego oraz ReflectionPermission flagą ReflectionPermissionFlag.MemberAccess . Kod uruchomiony z pełnym zaufaniem (na przykład kod w aplikacji uruchamianej z wiersza polecenia) zawsze może spełniać te uprawnienia. (Podlega to ograniczeniom w uzyskiwaniu dostępu do elementów członkowskich o znaczeniu krytycznym dla zabezpieczeń, zgodnie z opisem w dalszej części tego artykułu).

Opcjonalnie domena aplikacji w trybie piaskownicy może przyznać ReflectionPermission flagę ReflectionPermissionFlag.MemberAccess zgodnie z opisem w sekcji Uzyskiwanie dostępu do elementów członkowskich, które są zwykle niedostępne, w dalszej części tego artykułu.

Uzyskiwanie dostępu do elementów członkowskich o krytycznym znaczeniu dla zabezpieczeń

Element członkowski ma krytyczne znaczenie dla zabezpieczeń, jeśli ma SecurityCriticalAttributewartość , jeśli należy do typu , SecurityCriticalAttributelub jeśli znajduje się w zestawie krytycznym dla zabezpieczeń. Począwszy od programu .NET Framework 4, reguły uzyskiwania dostępu do elementów członkowskich o krytycznym znaczeniu dla zabezpieczeń są następujące:

  • Przezroczysty kod nie może używać odbicia w celu uzyskania dostępu do elementów członkowskich o znaczeniu krytycznym dla zabezpieczeń, nawet jeśli kod jest w pełni zaufany. Zgłaszany MethodAccessExceptionjest element , FieldAccessExceptionlub TypeAccessException .

  • Kod, który działa z częściowym zaufaniem, jest traktowany jako przezroczysty.

Te reguły są takie same, czy dostęp do elementu członkowskiego krytycznego pod względem zabezpieczeń jest uzyskiwany bezpośrednio przez skompilowany kod, czy uzyskiwany jest dostęp za pomocą odbicia.

Kod aplikacji uruchamiany z poziomu wiersza polecenia jest uruchamiany z pełnym zaufaniem. Jeśli nie jest ona oznaczona jako przezroczysta, może używać odbicia w celu uzyskania dostępu do elementów członkowskich o krytycznym znaczeniu dla zabezpieczeń. Gdy ten sam kod jest uruchamiany z częściowym zaufaniem (na przykład w domenie aplikacji w trybie piaskownicy), poziom zaufania zestawu określa, czy może uzyskać dostęp do kodu krytycznego dla zabezpieczeń: jeśli zestaw ma silną nazwę i jest zainstalowany w globalnej pamięci podręcznej zestawów, jest to zaufany zestaw i może wywoływać elementy członkowskie krytyczne dla zabezpieczeń. Jeśli nie jest zaufany, staje się przezroczysty, mimo że nie został oznaczony jako przezroczysty i nie może uzyskać dostępu do elementów członkowskich o znaczeniu krytycznym dla zabezpieczeń.

Emocje i przejrzystość

Począwszy od programu .NET Framework 4, środowisko uruchomieniowe języka wspólnego określa poziom przezroczystości typu lub elementu członkowskiego z kilku czynników, w tym poziom zaufania zestawu i poziom zaufania domeny aplikacji. Emocje ion udostępnia IsSecurityCriticalwłaściwości , IsSecuritySafeCriticaliIsSecurityTransparent, aby umożliwić odnajdywanie poziomu przezroczystości typu. W poniższej tabeli przedstawiono prawidłowe kombinacje tych właściwości.

Poziom zabezpieczeń IsSecurityCritical IsSecuritySafeCritical IsSecurityTransparent
Krytyczne true false false
Sejf krytyczne true true false
Transparent false false true

Użycie tych właściwości jest znacznie prostsze niż badanie adnotacji zabezpieczeń zestawu i jego typów, sprawdzanie bieżącego poziomu zaufania i próba zduplikowania reguł środowiska uruchomieniowego. Na przykład ten sam typ może mieć krytyczne znaczenie dla zabezpieczeń, gdy jest uruchamiany z poziomu wiersza polecenia lub przezroczysty pod kątem zabezpieczeń, gdy jest uruchamiany w domenie aplikacji w trybie piaskownicy.

W klasach MethodBase, , FieldInfoTypeBuilder, MethodBuilderi istnieją DynamicMethod podobne właściwości. (W przypadku innych abstrakcji odbicia i odbicia atrybuty zabezpieczeń są stosowane do skojarzonych metod, na przykład w przypadku właściwości, które są stosowane do metod dostępu właściwości).

Uzyskiwanie dostępu do elementów członkowskich, które są zwykle niedostępne

Aby użyć odbicia w celu wywołania elementów członkowskich, które są niedostępne zgodnie z regułami ułatwień dostępu środowiska uruchomieniowego języka wspólnego, kod musi mieć jedno z dwóch uprawnień:

  • Aby zezwolić kodowi na wywoływanie dowolnego elementu członkowskiego innego niżpublica: Kod musi zostać udzielony ReflectionPermission z flagą ReflectionPermissionFlag.MemberAccess .

    Uwaga

    Domyślnie zasady zabezpieczeń odrzucają to uprawnienie do kodu pochodzącego z Internetu. To uprawnienie nigdy nie powinno być przyznawane kodowi pochodzącemu z Internetu.

  • Aby zezwolić kodowi na wywoływanie dowolnego elementu członkowskiego niepublicowego, o ile zestaw grantów zestawu, który zawiera wywoływany element członkowski, jest taki sam jak w przypadku zestawu lub podzestawu zestawu zawierającego kod wywołujący: Kod musi zostać udzielony ReflectionPermission z flagą ReflectionPermissionFlag.RestrictedMemberAccess .

Załóżmy na przykład, że przyznajesz domenie aplikacji uprawnienia internetowe oraz ReflectionPermissionReflectionPermissionFlag.RestrictedMemberAccess flagę, a następnie uruchamiasz aplikację internetową z dwoma zestawami A i B.

  • Zestaw A może używać odbicia w celu uzyskania dostępu do prywatnych elementów członkowskich zestawu B, ponieważ zestaw dotacji B nie zawiera żadnych uprawnień, które nie zostały przyznane.

  • Zestaw A nie może używać odbicia w celu uzyskania dostępu do prywatnych elementów członkowskich zestawów .NET Framework, takich jak mscorlib.dll, ponieważ mscorlib.dll jest w pełni zaufana i dlatego ma uprawnienia, które nie zostały przyznane zestawowi A. Element MemberAccessException jest zgłaszany, gdy zabezpieczenia dostępu do kodu przeprowadzają stos w czasie wykonywania.

Serializacja

W przypadku serializacji SecurityPermission flaga SecurityPermissionAttribute.SerializationFormatter zapewnia możliwość pobierania i ustawiania elementów członkowskich typów z możliwością serializacji, niezależnie od ułatwień dostępu. To uprawnienie umożliwia kodowi odnajdywanie i zmienianie stanu prywatnego wystąpienia. (Oprócz udzielenia odpowiednich uprawnień, typ musi być oznaczony jako serializowalny w metadanych).

Parametry klasy Type MethodInfo

Unikaj pisania publicznych członków, którzy przyjmują MethodInfo parametry, zwłaszcza w przypadku zaufanego kodu. Takie elementy członkowskie mogą być bardziej narażone na złośliwy kod. Rozważmy na przykład publiczny element członkowski w wysoce zaufanym kodzie, który przyjmuje MethodInfo parametr . Załóżmy, że publiczny element członkowski pośrednio wywołuje metodę Invoke w podanym parametrze. Jeśli publiczny element członkowski nie wykonuje niezbędnych kontroli uprawnień, wywołanie Invoke metody zawsze powiedzie się, ponieważ system zabezpieczeń określa, że obiekt wywołujący jest wysoce zaufany. Nawet jeśli złośliwy kod nie ma uprawnień do bezpośredniego wywoływania metody, nadal może to zrobić pośrednio, wywołując członka publicznego.

Informacje o wersji

  • Począwszy od programu .NET Framework 4, przezroczysty kod nie może używać odbicia w celu uzyskania dostępu do elementów członkowskich o krytycznym znaczeniu dla zabezpieczeń.

  • Flaga ReflectionPermissionFlag.RestrictedMemberAccess jest wprowadzana w programie .NET Framework 2.0 z dodatkiem Service Pack 1. Wcześniejsze wersje programu .NET Framework wymagają ReflectionPermissionFlag.MemberAccess flagi dla kodu, który używa odbicia w celu uzyskania dostępu do niepublikacyjnych elementów członkowskich. Jest to uprawnienie, które nigdy nie powinno być przyznane częściowemu zaufanemu kodzie.

  • Począwszy od programu .NET Framework 2.0, używanie odbicia w celu uzyskania informacji o typach niepublicowych i elementach członkowskich nie wymaga żadnych uprawnień. We wcześniejszych wersjach ReflectionPermission wymagana jest flaga ReflectionPermissionFlag.TypeInformation .

Zobacz też