Najlepsze rozwiązania dotyczące częściowego zaufania

  • Artykuł

W tym artykule opisano najlepsze rozwiązania dotyczące uruchamiania programu Windows Communication Foundation (WCF) w środowisku częściowego zaufania.

Serializacja

Zastosuj te rozwiązania w przypadku korzystania z DataContractSerializer aplikacji częściowo zaufanej.

Wszystkie typy możliwe do serializacji muszą być jawnie oznaczone za pomocą atrybutu [DataContract] . Następujące techniki nie są obsługiwane w środowisku częściowo zaufania:

  • Oznaczanie klas do serializacji za pomocą klasy SerializableAttribute.
  • Implementowanie interfejsu w celu umożliwienia ISerializable klasie kontrolowania procesu serializacji.

Korzystanie z elementu DataContractSerializer

  • Wszystkie typy oznaczone atrybutem [DataContract] muszą być publiczne. Nie można serializować typów innych niż publiczne w środowisku częściowego zaufania.

  • Wszystkie [DataContract] elementy członkowskie w typie z możliwością [DataContract] serializacji muszą być publiczne. Nie można serializować typu z niepublikiem [DataMember] w środowisku częściowego zaufania.

  • Metody obsługujące zdarzenia serializacji (takie jak OnSerializing, , OnSerializedOnDeserializingi OnDeserialized) muszą być zadeklarowane jako publiczne. Obsługiwane są jednak zarówno jawne, jak i niejawne implementacje programu OnDeserialization(Object) .

  • [DataContract] typy zaimplementowane w zestawach oznaczonych jako AllowPartiallyTrustedCallersAttribute nie mogą wykonywać akcji związanych z zabezpieczeniami w konstruktorze typu, ponieważ DataContractSerializer konstruktor nowo utworzonego obiektu podczas deserializacji nie wywołuje konstruktora. W szczególności należy unikać następujących typowych technik zabezpieczeń:[DataContract]

  • Próba ograniczenia dostępu częściowego zaufania przez wprowadzenie konstruktora typu wewnętrznego lub prywatnego.

  • Ograniczanie dostępu do typu przez dodanie elementu [LinkDemand] do konstruktora typu.

  • Zakładając, że ponieważ obiekt został pomyślnie utworzone, wszystkie testy poprawności wymuszone przez konstruktor zostały pomyślnie zakończone pomyślnie.

Korzystanie z elementu IXmlSerializable

Poniższe najlepsze rozwiązania dotyczą typów, które implementują IXmlSerializable i są serializowane przy użyciu klasy DataContractSerializer:

  • GetSchema Implementacje metody statycznej muszą mieć wartość public.

  • Metody wystąpienia implementujące IXmlSerializable interfejs muszą mieć wartość public.

Korzystanie z programu WCF z w pełni zaufanego kodu platformy, który umożliwia wywołania z częściowo zaufanych wywołujących

Model zabezpieczeń częściowego zaufania WCF zakłada, że każdy obiekt wywołujący metodę publiczną lub właściwość WCF jest uruchomiony w kontekście zabezpieczeń dostępu kodu (CAS) aplikacji hostingu. WCF zakłada również, że istnieje tylko jeden kontekst zabezpieczeń aplikacji dla każdego AppDomainelementu i że ten kontekst jest ustanawiany w AppDomain czasie tworzenia przez zaufanego hosta (na przykład przez wywołanie lub CreateDomain przez ASP.NET Application Manager).

Uwaga

Zabezpieczenia dostępu kodu (CAS) zostały wycofane we wszystkich wersjach programu .NET Framework i .NET. Najnowsze wersje platformy .NET nie honorują adnotacji CAS i generują błędy, jeśli są używane interfejsy API związane z usługą CAS. Deweloperzy powinni szukać alternatywnych sposobów wykonywania zadań zabezpieczeń.

Ten model zabezpieczeń dotyczy aplikacji napisanych przez użytkownika, które nie mogą uzyskać dodatkowych uprawnień cas, takich jak kod użytkownika uruchomiony w aplikacji ASP.NET Medium Trust. Jednak w pełni zaufany kod platformy (na przykład zestaw innej firmy, który jest zainstalowany w globalnej pamięci podręcznej zestawów i akceptuje wywołania z częściowo zaufanego kodu) musi mieć jawną ostrożność podczas wywoływania do usługi WCF w imieniu częściowo zaufanej aplikacji, aby uniknąć wprowadzania luk w zabezpieczeniach na poziomie aplikacji.

Kod pełnego zaufania powinien unikać zmiany zestawu uprawnień CAS bieżącego wątku (wywołując metodę , PermitOnlylub Deny) przed wywołaniem Assertinterfejsów API WCF w imieniu częściowo zaufanego kodu. Potwierdzenie, odmowa lub w inny sposób utworzenie kontekstu uprawnień specyficznego dla wątku, który jest niezależny od kontekstu zabezpieczeń na poziomie aplikacji, może spowodować nieoczekiwane zachowanie. W zależności od aplikacji to zachowanie może spowodować luki w zabezpieczeniach na poziomie aplikacji.

Kod wywołujący program WCF przy użyciu kontekstu uprawnień specyficznych dla wątku musi być przygotowany do obsługi następujących sytuacji, które mogą wystąpić:

  • Kontekst zabezpieczeń specyficzny dla wątku może nie być utrzymywany przez czas trwania operacji, co powoduje potencjalne wyjątki zabezpieczeń.

  • Wewnętrzny kod WCF i wszystkie wywołania zwrotne dostarczane przez użytkownika mogą być uruchamiane w innym kontekście zabezpieczeń niż ten, w którym wywołanie zostało pierwotnie zainicjowane. Te konteksty obejmują:

    • Kontekst uprawnień aplikacji.

    • Dowolny kontekst uprawnień specyficznych dla wątku utworzony wcześniej przez inne wątki użytkownika używane do wywoływania do programu WCF w okresie istnienia aktualnie uruchomionego AppDomainelementu .

WCF gwarantuje, że częściowo zaufany kod nie może uzyskać uprawnień pełnego zaufania, chyba że takie uprawnienia są potwierdzane przez w pełni zaufany składnik przed wywołaniem publicznych interfejsów API programu WCF. Nie gwarantuje jednak, że skutki potwierdzenia pełnego zaufania są odizolowane od określonego wątku, operacji lub akcji użytkownika.

Najlepszym rozwiązaniem jest unikanie tworzenia kontekstu uprawnień specyficznych dla wątków przez wywołanie metody Assert, PermitOnlylub Deny. Zamiast tego przyznaj lub odmów uprawnienia do samej aplikacji, aby nie było wymagane żadne AssertDeny, lubPermitOnly.

Zobacz też