Procedure consigliate in ambienti parzialmente attendibili

Questo articolo descrive le procedure consigliate per l'esecuzione di Windows Communication Foundation (WCF) in un ambiente parzialmente attendibile.

Serializzazione

Applicare queste procedure quando si utilizza DataContractSerializer in un'applicazione parzialmente attendibile.

Tutti i tipi serializzabili devono essere contrassegnati in modo esplicito con l'attributo [DataContract]. Le tecniche seguenti non sono supportate in un ambiente parzialmente attendibile:

  • Contrassegno delle classi da serializzare con SerializableAttribute.
  • Implementazione dell'interfaccia ISerializable per consentire a una classe di controllare il suo processo di serializzazione.

Utilizzo di DataContractSerializer

  • Tutti i tipi contrassegnati con l'attributo [DataContract] devono essere pubblici. Impossibile serializzare tipi non pubblici in un ambiente parzialmente attendibile.

  • I membri [DataContract] in un tipo [DataContract] serializzabile devono essere pubblici. Un tipo con un [DataMember] non pubblico non può essere serializzato in un ambiente parzialmente attendibile.

  • I metodi che gestiscono eventi di serializzazione (ad esempio OnSerializing, OnSerialized, OnDeserializing e OnDeserialized) devono essere dichiarati pubblici. Sono tuttavia supportate le implementazioni sia esplicite che implicite di OnDeserialization(Object).

  • I tipi [DataContract] implementati in assembly contrassegnati con AllowPartiallyTrustedCallersAttribute non devono eseguire azioni correlate alla protezione nel costruttore del tipo, poiché DataContractSerializer non chiama il costruttore dell'oggetto di cui è appena stata creata un'istanza durante la deserializzazione. In particolare, è necessario evitare le tecniche di sicurezza comuni seguenti per i tipi [DataContract]:

  • Tentare di limitare l'accesso parzialmente attendibile rendendo interno o privato il costruttore del tipo.

  • Limitare l'accesso al tipo aggiungendo un [LinkDemand] al costruttore del tipo.

  • Dare per scontato che, dato che l'istanza dell'oggetto è stata creata correttamente, qualsiasi controllo di convalida applicato dal costruttore abbia avuto esito positivo.

Utilizzo di IXmlSerializable

Le procedure consigliate seguenti si applicano ai tipi che implementano IXmlSerializable e che vengono serializzati tramite DataContractSerializer:

  • Le implementazioni del metodo statico GetSchema devono essere public.

  • I metodi di istanza che implementano l'interfaccia IXmlSerializable devono essere public.

Utilizzo di WCF da codice della piattaforma completamente attendibile che consente chiamate da chiamanti parzialmente attendibili

Nel modello di sicurezza parzialmente attendibile di WCF si presuppone che qualsiasi chiamante di una proprietà o un metodo pubblico di WCF sia in esecuzione nel contesto di sicurezza dall'accesso di codice (CAS, Code Access Security) dell'applicazione host. In WCF si presuppone inoltre che esista un solo contesto di sicurezza dell'applicazione per ogni AppDomain e che questo contesto sia stabilito al momento della creazione di AppDomain da un host attendibile (ad esempio, da una chiamata a CreateDomain o da Gestione applicazioni ASP.NET).

Nota

La sicurezza dall'accesso al codice (CAS) è stata deprecata in tutte le versioni di .NET Framework e .NET. Le versioni recenti di .NET non rispettano le annotazioni CAS e generano errori se vengono usate API correlate alla CAS. Gli sviluppatori devono cercare mezzi alternativi per eseguire attività di sicurezza.

Questo modello di sicurezza si applica alle applicazioni scritte dall'utente che non possono richiedere autorizzazioni CAS aggiuntive, ad esempio codice utente in esecuzione in un'applicazione ASP.NET con un livello di attendibilità medio. Tuttavia, per il codice della piattaforma completamente attendibile, ad esempio un assembly di terze parti installato nella Global Assembly Cache che accetta chiamate da codice parzialmente attendibile, occorre fare esplicitamente attenzione in caso di chiamata a WCF per conto di un'applicazione parzialmente attendibile al fine di evitare eventuali vulnerabilità della sicurezza a livello di applicazione.

Il codice di attendibilità totale deve evitare di modificare l'autorizzazione CAS impostata del thread corrente (chiamando Assert, PermitOnly o Deny) prima di chiamare API WCF per conto di codice parzialmente attendibile. L'asserzione, la negazione o la creazione di un contesto di autorizzazione specifico del thread che è indipendente dal contesto di sicurezza a livello di applicazione possono dare luogo a un comportamento imprevisto. A seconda dell'applicazione, questo comportamento può comportare vulnerabilità di sicurezza a livello di applicazione.

Il codice che effettua chiamate a WCF utilizzando un contesto di autorizzazione specifico del thread deve essere preparato a gestire le situazioni seguenti che possono presentarsi:

  • Il contesto di sicurezza specifico del thread potrebbe non essere mantenuto per la durata dell'operazione, il che comporta potenziali eccezioni di sicurezza.

  • Il codice interno di WCF così come qualsiasi callback fornito dall'utente potrebbero venire eseguiti in un contesto di sicurezza diverso da quello in cui è iniziata originariamente la chiamata. Questi contesti includono:

    • Il contesto di autorizzazione dell'applicazione.

    • Qualsiasi contesto di autorizzazione specifico del thread creato in precedenza da altri thread dell'utente utilizzato per eseguire chiamate a WCF nel corso della durata di AppDomain attualmente in esecuzione.

WCF garantisce che il codice parzialmente attendibile non possa ottenere autorizzazioni di attendibilità totale a meno che tali autorizzazioni non vengano asserite da un componente completamente attendibile prima di chiamare le API pubbliche di WCF. Non garantisce, tuttavia, che gli effetti dell'asserzione di attendibilità totale siano isolati in un thread, operazione o azione dell'utente specifico.

Come procedura consigliata, evitare di creare un contesto di autorizzazione specifico del thread chiamando Assert, PermitOnly o Deny. In alternativa, concedere o negare il privilegio all'applicazione stessa, così che non sia necessario Assert, Deny o PermitOnly.

Vedi anche