Considerazioni sulla sicurezza XAML

Questo articolo descrive le procedure consigliate per la sicurezza nelle applicazioni quando usi l'API dei servizi XAML e .NET.

XAML non attendibile nelle applicazioni

Nel senso più generale, XAML non attendibile è qualsiasi origine XAML che l'applicazione non include o genera in modo specifico.

XAML compilato o archiviato come risorsa di tipo resxall'interno di un assembly attendibile e firmato non è intrinsecamente non attendibile. È possibile considerare attendibile il codice XAML nel modo in cui si considera attendibile l'assembly nel suo complesso. Nella maggior parte dei casi, si è interessati solo agli aspetti di attendibilità di XAML libero, che è un'origine XAML che si carica da un flusso o da un altro I/O. XAML libero non è un componente specifico o una funzionalità di un modello di applicazione con un'infrastruttura di distribuzione e creazione di pacchetti. Tuttavia, un assembly potrebbe implementare un comportamento che comporta il caricamento di XAML separati.

Per XAML non attendibile, è consigliabile considerarlo in genere come se fosse codice non attendibile. Usa sandboxing o altre metafore per evitare che XAML non attendibile acceda al codice attendibile.

La natura delle funzionalità XAML offre al codice XAML il diritto di costruire oggetti e impostarne le proprietà. Queste funzionalità includono anche l'accesso ai convertitori di tipi, il mapping e l'accesso agli assembly nel dominio applicazione, l'uso di estensioni di markup, i blocchi x:Code e così via.

Oltre alle funzionalità a livello di linguaggio, XAML viene usato per la definizione dell'interfaccia utente in molte tecnologie. Il caricamento di XAML non attendibile potrebbe significare il caricamento di un'interfaccia utente di spoofing dannosa.

Moduli compilati e binari di XAML

Alcune tecnologie compilano XAML in un formato binario o tokenizzato caricato in fase di esecuzione. Una forma binaria di XAML ha le stesse funzionalità di costruzione di oggetti del codice XAML di testo equivalente, quindi comporta le stesse considerazioni di attendibilità. Considera un'origine XAML binaria attendibile solo quando ha origine da un assembly compilato, firmato o una risorsa prodotta. Non caricare un'origine XAML binaria proveniente da un flusso, un file o un documento non attendibile e tenere presente che un formato contenitore potrebbe incorporare tale contenuto come una delle relative parti.

I lettori restrittivi sono una misura di protezione avanzata, non una sandbox

Un percorso di caricamento può offrire un lettore restrittivo o consentito che blocca un set di tipi pericolosi noti. Questo tipo di lettore è un passaggio utile per la protezione avanzata, ma non è una sandbox di sicurezza. Un lettore restrittivo può comunque consentire molti tipi predefiniti, inclusi i tipi con effetti collaterali, ad esempio il raggiungimento delle risorse di rete. Non considerare un'analisi restrittiva del markup non attendibile come sicura. Continuare a isolare il markup non attendibile in un limite con privilegi limitati.

Condivisione del contesto tra lettori e writer

L'architettura dei servizi XAML .NET per lettori XAML e writer XAML spesso richiede la condivisione di un lettore XAML a un writer XAML o a un contesto di schema XAML condiviso. La condivisione di oggetti o contesti potrebbe essere necessaria se si scrive la logica del ciclo di nodi XAML o si fornisce un percorso di salvataggio personalizzato. Non condividere istanze del lettore XAML, contesto dello schema XAML non predefinito o impostazioni per le classi lettore/writer XAML tra codice attendibile e non attendibile.

La maggior parte degli scenari e delle operazioni che coinvolgono la scrittura di oggetti XAML per un supporto basato su CLR può usare solo il contesto dello schema XAML predefinito. Il contesto dello schema XAML predefinito non include in modo esplicito le impostazioni che potrebbero compromettere l'attendibilità totale. È quindi sicuro condividere il contesto tra componenti di lettore/writer XAML attendibili e non attendibili. Tuttavia, se si esegue questa operazione, è comunque consigliabile mantenere tali lettori e writer in ambiti separati AppDomain, con uno di essi specificamente destinato/in modalità sandbox per l'attendibilità parziale.

Spazi dei nomi XAML e attendibilità assembly

La sintassi e la definizione non qualificate di base per il modo in cui XAML interpreta un mapping di spazi dei nomi XAML personalizzato a un assembly non distingue tra un assembly attendibile e non attendibile come caricato nel dominio dell'applicazione. Di conseguenza, è tecnicamente possibile che un assembly non attendibile esepri il mapping dello spazio dei nomi XAML previsto di un assembly attendibile e acquisisca le informazioni sull'oggetto e sulle proprietà dichiarate di un'origine XAML. Se hai requisiti di sicurezza per evitare questa situazione, il mapping dello spazio dei nomi XAML previsto deve essere eseguito usando una delle tecniche seguenti:

• Usa un nome di assembly completo con nome sicuro in qualsiasi mapping dello spazio dei nomi XAML creato dal codice XAML dell'applicazione.

• Limitare il mapping degli assembly a un set fisso di assembly di riferimento creando un XamlSchemaContext specifico per i lettori XAML e i writer di oggetti XAML. Vedere XamlSchemaContext(IEnumerable<Assembly>).

Mapping dei tipi XAML e accesso al sistema dei tipi

XAML supporta il proprio sistema di tipi, che in molti modi è un peer del modo in cui CLR implementa il sistema di tipi CLR di base. Tuttavia, per determinati aspetti di consapevolezza dei tipi in cui si stanno prendendo decisioni di attendibilità su un tipo in base alle relative informazioni sul tipo, è consigliabile rinviare le informazioni sul tipo nei tipi di supporto CLR. Ciò è dovuto al fatto che alcune delle funzionalità di creazione di report specifiche del sistema di tipi XAML vengono lasciate aperte come metodi virtuali e pertanto non sono completamente sotto il controllo delle implementazioni originali dei servizi XAML .NET. Questi punti di estendibilità esistono perché il sistema di tipi XAML è estendibile, in modo che corrisponda all'estendibilità di XAML stesso e alle possibili strategie alternative di mapping dei tipi rispetto all'implementazione predefinita supportata da CLR e al contesto dello schema XAML predefinito. Per altre informazioni, vedere le note specifiche su diverse proprietà di XamlType e XamlMember.

Vedere anche

• XamlAccessLevel