Condividi tramite

Problemi di sicurezza in Reflection Emit

.NET Framework offre tre modi per generare un linguaggio intermedio comune (CIL), ognuno con i propri problemi di sicurezza:

Indipendentemente dal modo in cui si genera codice dinamico, l'esecuzione del codice generato richiede tutte le autorizzazioni richieste dai tipi e dai metodi usati dal codice generato.

Annotazioni

Le autorizzazioni necessarie per riflettere sul codice e l'emissione di codice sono state modificate con le versioni successive di .NET Framework. Vedere Informazioni sulla versione più avanti in questo articolo.

Assembly dinamiche

Gli assembly dinamici vengono creati usando i sovraccarichi del metodo AppDomain.DefineDynamicAssembly. La maggior parte degli overload di questo metodo è deprecata in .NET Framework 4, a causa dell'eliminazione dei criteri di sicurezza a livello di computer. Gli overload rimanenti possono essere eseguiti da qualsiasi codice, indipendentemente dal livello di attendibilità. Questi overload rientrano in due gruppi: quelli che specificano un elenco di attributi da applicare all'assembly dinamico al momento della creazione e quelli che non lo fanno. Se non si specifica il modello di trasparenza per l'assembly applicando l'attributo SecurityRulesAttribute quando lo si crea, il modello di trasparenza viene ereditato dall'assembly emittente.

Annotazioni

Gli attributi applicati all'assembly dinamico dopo la creazione, usando il SetCustomAttribute metodo , non diventano effettivi finché l'assembly non viene salvato su disco e caricato nuovamente in memoria.

Il codice in un assembly dinamico può accedere a tipi e membri visibili in altri assembly.

Annotazioni

Gli assembly dinamici non usano i ReflectionPermissionFlag.MemberAccess flag e ReflectionPermissionFlag.RestrictedMemberAccess che consentono ai metodi dinamici di accedere a tipi e membri non pubblici.

Gli assembly dinamici temporanei vengono creati in memoria e non vengono mai salvati su disco, quindi non richiedono autorizzazioni di accesso ai file. Il salvataggio di un assembly dinamico su disco richiede FileIOPermission con i flag appropriati.

Generazione di assemblaggi dinamici da codice parzialmente attendibile

Si considerino le condizioni in cui un assembly con autorizzazioni Internet può generare un assembly dinamico temporaneo ed eseguirne il codice:

  • L'assembly dinamico utilizza solo tipi e membri pubblici di altri assembly.

  • Le autorizzazioni richieste da tali tipi e membri sono incluse nel set di concessioni dell'assembly con fiducia parziale.

  • L'assemblaggio non viene salvato su disco.

  • I simboli di debug non vengono generati. (Internet e LocalIntranet i set di autorizzazioni non includono le autorizzazioni necessarie.

Metodi dinamici ospitati in modo anonimo

I metodi dinamici ospitati in modo anonimo vengono creati usando i due DynamicMethod costruttori che non specificano un tipo o un modulo DynamicMethod(String, Type, Type[]) associato e DynamicMethod(String, Type, Type[], Boolean). Questi costruttori inseriscono i metodi dinamici in un assembly trasparente alla sicurezza e totalmente affidabile fornito dal sistema. Non sono necessarie autorizzazioni per usare questi costruttori o per generare codice per i metodi dinamici.

Al contrario, quando viene creato un metodo dinamico ospitato in modo anonimo, viene acquisito lo stack di chiamate. Quando il metodo viene costruito, le richieste di sicurezza vengono eseguite sullo stack di chiamate acquisito.

Annotazioni

Concettualmente, le richieste vengono effettuate durante la costruzione del metodo. Ciò significa che le richieste possono essere effettuate ogni volta che viene emessa ogni istruzione CIL. Nell'implementazione corrente vengono eseguite tutte le richieste quando viene chiamato il DynamicMethod.CreateDelegate metodo o quando viene richiamato il compilatore JIT (Just-In-Time), se il metodo viene richiamato senza chiamare CreateDelegate.

Se il dominio dell'applicazione lo consente, i metodi dinamici ospitati anonimamente possono ignorare i controlli di visibilità JIT, soggetti alla seguente restrizione: i tipi e i membri non pubblici a cui accede un metodo dinamico ospitato anonimamente devono trovarsi in assembly i cui set di concessioni sono uguali o sottoinsiemi del set di concessioni dello stack di chiamate dell'emittente. Questa capacità limitata di saltare i controlli di visibilità JIT è attivata se il dominio dell'applicazione concede ReflectionPermission con il flag ReflectionPermissionFlag.RestrictedMemberAccess.

  • Se il metodo usa solo tipi e membri pubblici, non sono necessarie autorizzazioni durante la costruzione.

  • Se si specifica che i controlli di visibilità JIT devono essere ignorati, la richiesta che viene fatta durante la costruzione del metodo include ReflectionPermission con il ReflectionPermissionFlag.RestrictedMemberAccess flag e il set di autorizzazioni dell'assembly che contiene il membro non pubblico a cui si accede.

Poiché il set di concessioni del membro non pubblico viene preso in considerazione, il codice parzialmente attendibile concesso ReflectionPermissionFlag.RestrictedMemberAccess non può elevare i privilegi eseguendo membri non pubblici di assembly attendibili.

Come per qualsiasi altro codice generato, l'esecuzione del metodo dinamico richiede qualsiasi autorizzazione richiesta dai metodi usati dal metodo dinamico.

L'assembly di sistema che ospita metodi dinamici ospitati in modo anonimo usa il modello di SecurityRuleSet.Level1 trasparenza, ovvero il modello di trasparenza usato in .NET Framework prima di .NET Framework 4.

Per altre informazioni, vedere la classe DynamicMethod.

Generazione di metodi dinamici ospitati in modo anonimo da codice parzialmente attendibile

Considerare le condizioni in cui un assembly con autorizzazioni Internet può generare un metodo dinamico ospitato in modo anonimo ed eseguirlo:

  • Il metodo dinamico usa solo tipi e membri pubblici. Se il set di concessioni include ReflectionPermissionFlag.RestrictedMemberAccess, può usare tipi e membri non pubblici di qualsiasi assembly il cui set di concessioni sia uguale a, o un sottoinsieme del set di concessioni dell'assembly di creazione.

  • Le autorizzazioni richieste da tutti i tipi e i membri utilizzati dal metodo dinamico sono incluse nell'insieme di concessioni dell'assembly con attendibilità parziale.

Annotazioni

I metodi dinamici non supportano i simboli di debug.

Metodi dinamici associati agli assembly esistenti

Per associare un metodo dinamico a un tipo o a un modulo in un assembly esistente, utilizzare uno dei DynamicMethod costruttori che specificano il tipo o il modulo associato. Le autorizzazioni necessarie per chiamare questi costruttori variano perché l'associazione di un metodo dinamico a un tipo o a un modulo esistente concede al metodo dinamico l'accesso a tipi e membri non pubblici:

  • Un metodo dinamico associato a un tipo ha accesso a tutti i membri di tale tipo, anche ai membri privati e a tutti i tipi e membri interni nell'assembly che contiene il tipo associato.

  • Un metodo dinamico associato a un modulo ha accesso a tutti i internal tipi e i membri (Friend in Visual Basic, assembly nei metadati di Common Language Runtime) nel modulo.

Inoltre, è possibile usare un costruttore che specifica la possibilità di ignorare i controlli di visibilità del compilatore JIT. In questo modo, il metodo dinamico può accedere a tutti i tipi e ai membri in tutti gli assembly, indipendentemente dal livello di accesso.

Le autorizzazioni richieste dal costruttore dipendono dalla quantità di accesso che si decide di assegnare al metodo dinamico:

Anche se gli elementi in questo elenco sono descritti in termini di set di concessioni dell'assembly di emissione, ricordare che le richieste vengono effettuate rispetto allo stack di chiamate completo, incluso il limite del dominio dell'applicazione.

Per altre informazioni, vedere la classe DynamicMethod.

Generazione di metodi dinamici da codice parzialmente attendibile

Annotazioni

Il modo consigliato per generare metodi dinamici da codice parzialmente attendibile consiste nell'usare metodi dinamici ospitati in modo anonimo.

Considerare le condizioni in cui un assembly con autorizzazioni Internet può generare un metodo dinamico ed eseguirlo:

  • Il metodo dinamico è associato al modulo o al tipo che lo genera, oppure il suo insieme di permessi include ReflectionPermissionFlag.RestrictedMemberAccess ed è associato a un modulo in un assembly il cui insieme di permessi è uguale o è un sottoinsieme dell'insieme di permessi dell'assembly emissivo.

  • Il metodo dinamico usa solo tipi e membri pubblici. Se il set di concessioni include ReflectionPermissionFlag.RestrictedMemberAccess ed è associato a un modulo in un assembly il cui set di concessioni è uguale o costituisce un sottoinsieme del set di concessioni dell'assembly di emissione, può usare tipi e membri contrassegnati internal (Friend in Visual Basic, assembly nei metadati di runtime di linguaggio comune) nel modulo associato.

  • Le autorizzazioni richieste da tutti i tipi e i membri usati dal metodo dinamico sono incluse nel set di concessioni dell'assembly parzialmente attendibile.

  • Il metodo dinamico non ignora i controlli di visibilità JIT.

Annotazioni

I metodi dinamici non supportano i simboli di debug.

Informazioni sulla versione

A partire da .NET Framework 4, i criteri di sicurezza a livello di computer vengono eliminati e la trasparenza della sicurezza diventa il meccanismo di imposizione predefinito.

A partire da .NET Framework 2.0 Service Pack 1, ReflectionPermission con il flag ReflectionPermissionFlag.ReflectionEmit non è più necessario quando si generano assemblati dinamici e metodi dinamici. Questo flag è obbligatorio in tutte le versioni precedenti di .NET Framework.

Annotazioni

ReflectionPermission con il flag ReflectionPermissionFlag.ReflectionEmit è incluso per impostazione predefinita nei set di autorizzazioni denominati FullTrust e LocalIntranet, ma non nel set di autorizzazioni Internet. Pertanto, nelle versioni precedenti di .NET Framework, una libreria può essere usata con autorizzazioni Internet solo se esegue un Assert per ReflectionEmit. Tali librerie richiedono un'attenta revisione della sicurezza perché gli errori di codifica potrebbero causare problemi di sicurezza. .NET Framework 2.0 SP1 consente l'emissione di codice in scenari di attendibilità parziale senza emettere alcuna richiesta di sicurezza, perché la generazione di codice non è intrinsecamente un'operazione con privilegi. Ovvero, il codice generato non ha più autorizzazioni rispetto all'assembly che lo genera. Ciò consente alle librerie che generano codice di essere trasparenti per la sicurezza e rimuove la necessità di asserire ReflectionEmit, semplificando così l'attività di scrittura di una libreria sicura.

.NET Framework 2.0 SP1 introduce inoltre il flag ReflectionPermissionFlag.RestrictedMemberAccess per l'accesso a tipi e membri non pubblici da metodi dinamici con attendibilità parziale. Le versioni precedenti di .NET Framework richiedono il ReflectionPermissionFlag.MemberAccess flag per i metodi dinamici che accedono a tipi e membri non pubblici. Si tratta di un'autorizzazione che non deve mai essere concessa a codice parzialmente attendibile.

Infine, .NET Framework 2.0 SP1 introduce metodi ospitati in modo anonimo.

Recupero di informazioni su tipi e membri

A partire da .NET Framework 2.0, non sono necessarie autorizzazioni per ottenere informazioni su tipi e membri non pubblici. La riflessione viene usata per ottenere le informazioni necessarie per emettere metodi dinamici. Ad esempio, MethodInfo gli oggetti vengono usati per generare chiamate al metodo. Le versioni precedenti di .NET Framework richiedono ReflectionPermission con il parametro ReflectionPermissionFlag.TypeInformation. Per ulteriori informazioni, vedere Considerazioni sulla sicurezza per la riflessione.

Vedere anche

  • Last updated on