Condividi tramite

Considerazioni sulla sicurezza per la riflessione

La Reflection consente di ottenere informazioni sui tipi e sui membri e di accedere ai membri, come chiamare metodi e costruttori, ottenere e impostare i valori delle proprietà, aggiungere e rimuovere gestori eventi e così via. L'uso della riflessione per ottenere informazioni sulle classi e sui membri non è limitato. Tutto il codice può usare la reflection per eseguire le attività seguenti:

  • Enumerare tipi e membri ed esaminare i relativi metadati.
  • Enumerare ed esaminare assembly e moduli.

L'uso della reflection per accedere ai membri, al contrario, è soggetto a restrizioni. A partire da .NET Framework 4, solo il codice attendibile può usare la reflection per accedere ai membri critici per la sicurezza. Inoltre, solo il codice attendibile può usare la reflection per accedere a membri non pubblici che non sarebbero direttamente accessibili al codice compilato. Infine, il codice che usa la reflection per accedere a un membro critico sicuro deve disporre di qualsiasi autorizzazione richiesta dal membro critico sicuro, come per il codice compilato.

Soggetto alle autorizzazioni necessarie, il codice può usare la reflection per eseguire i tipi di accesso seguenti:

  • Accedere ai membri pubblici che non sono fondamentali per la sicurezza.

  • Accedere a membri non pubblici accessibili al codice compilato, se tali membri non sono critici per la sicurezza. Esempi di tali membri non pubblici includono:

    • Membri protetti delle classi di base del codice chiamante. (In riflessione, questo viene definito accesso a livello di famiglia.)

    • internal membri (Friend membri in Visual Basic) nell'assembly del codice chiamante. Nel contesto della reflection, questa operazione viene definita accesso a livello di assembly.

    • Membri privati di altre istanze della classe che ospita il codice chiamante.

Ad esempio, il codice eseguito in un dominio applicazione in modalità sandbox è limitato all'accesso descritto in questo elenco, a meno che il dominio dell'applicazione non conceda autorizzazioni aggiuntive.

A partire da .NET Framework 2.0 Service Pack 1, l'accesso ai membri normalmente non accessibili genera una richiesta per il set di autorizzazioni dell'oggetto di destinazione più ReflectionPermission con il ReflectionPermissionFlag.MemberAccess contrassegno. Il codice in esecuzione con attendibilità totale , ad esempio il codice in un'applicazione avviata dalla riga di comando, può sempre soddisfare queste autorizzazioni. Questo è soggetto alle limitazioni per l'accesso ai membri critici per la sicurezza, come descritto più avanti in questo articolo.

Facoltativamente, un dominio applicazione sandboxato può concedere ReflectionPermission con il flag ReflectionPermissionFlag.MemberAccess, come descritto nella sezione Accesso ai membri normalmente inaccessibili, più avanti in questo articolo.

Accesso ai membri di Security-Critical

Un membro è critico per la sicurezza se ha il SecurityCriticalAttribute, se appartiene a un tipo che ha il SecurityCriticalAttribute, o se si trova in un assembly critico per la sicurezza. A partire da .NET Framework 4, le regole per l'accesso ai membri critici per la sicurezza sono le seguenti:

  • Il codice trasparente non può usare la reflection per accedere ai membri critici per la sicurezza, anche se il codice è completamente attendibile. MethodAccessException, FieldAccessException o TypeAccessException viene generato.

  • Il codice in esecuzione con attendibilità parziale viene considerato trasparente.

Queste regole sono uguali se un membro critico per la sicurezza è accessibile direttamente dal codice compilato o accessibile tramite reflection.

Il codice dell'applicazione eseguito dalla riga di comando viene eseguito con attendibilità totale. Purché non sia contrassegnato come trasparente, può usare reflection per accedere ai membri sensibili alla sicurezza. Quando lo stesso codice viene eseguito con attendibilità parziale (ad esempio, in un dominio dell'applicazione in modalità sandbox), il livello di attendibilità dell'assembly determina se può accedere al codice critico per la sicurezza: se l'assembly ha un nome sicuro e viene installato nella Global Assembly Cache, si tratta di un assembly attendibile e può chiamare membri critici per la sicurezza. Se non è attendibile, diventa trasparente anche se non è stato contrassegnato come trasparente e non può accedere ai membri critici per la sicurezza.

Reflection e trasparenza

A partire da .NET Framework 4, Common Language Runtime determina il livello di trasparenza di un tipo o di un membro da diversi fattori, tra cui il livello di attendibilità dell'assembly e il livello di attendibilità del dominio applicazione. La riflessione fornisce le proprietà IsSecurityCritical, IsSecuritySafeCritical e IsSecurityTransparent per consentire di individuare il livello di trasparenza di un tipo. Nella tabella seguente vengono illustrate le combinazioni valide di queste proprietà.

Livello di sicurezza ÈCriticoPerLaSicurezza IsSecuritySafeCritical IsSecurityTransparent
Critico true false false
Critico per la sicurezza true true false
Trasparente false false true

L'uso di queste proprietà è molto più semplice rispetto all'analisi delle annotazioni di sicurezza di un assembly e dei relativi tipi, al controllo del livello di attendibilità corrente e al tentativo di duplicare le regole del runtime. Ad esempio, lo stesso tipo può essere critico per la sicurezza quando viene eseguito dalla riga di comando o trasparente per la sicurezza quando viene eseguito in un dominio applicazione in modalità sandbox.

Esistono proprietà simili nelle MethodBaseclassi , FieldInfo, TypeBuilderMethodBuilder, e DynamicMethod . Per altre astrazioni di riflessione e di emissione delle astrazioni di riflessione, gli attributi di sicurezza vengono applicati ai metodi associati; per esempio, nel caso delle proprietà, vengono applicati agli accessori delle proprietà.

Accesso ai membri normalmente inaccessibili

Per usare la reflection per richiamare i membri inaccessibili in base alle regole di accessibilità di Common Language Runtime, è necessario concedere al codice una delle due autorizzazioni seguenti:

  • Per consentire al codice di richiamare qualsiasi membro non pubblico: il codice deve essere concesso ReflectionPermission con il ReflectionPermissionFlag.MemberAccess flag .

    Annotazioni

    Per impostazione predefinita, i criteri di sicurezza negano questa autorizzazione al codice originato da Internet. Questa autorizzazione non deve mai essere concessa al codice originato da Internet.

  • Per consentire al codice di richiamare qualsiasi membro non pubblico, purché il set di concessioni dell'assembly che contiene il membro richiamato sia uguale o un sottoinsieme del set di concessioni dell'assembly che contiene il codice chiamante, il vostro codice deve essere concesso ReflectionPermission con il flag ReflectionPermissionFlag.RestrictedMemberAccess.

Si supponga, ad esempio, di concedere a un dominio applicativo le autorizzazioni Internet insieme al flag ReflectionPermission, e quindi di eseguire un'applicazione Internet con due assembly, A e B.

  • L'assembly A può usare la reflection per accedere ai membri privati dell'assembly B, perché il set di concessioni di assembly B non include autorizzazioni non concesse a A.

  • L'assembly A non può usare la reflection per accedere ai membri privati degli assembly .NET Framework, come mscorlib.dll, perché mscorlib.dll è completamente attendibile e dispone di autorizzazioni non concesse all'assembly A. Un'eccezione MemberAccessException viene generata quando la sicurezza dell'accesso al codice (CAS) verifica lo stack in fase di esecuzione.

Serializzazione

Per la serializzazione, SecurityPermission con il flag SecurityPermissionAttribute.SerializationFormatter consente di ottenere e impostare membri di tipi serializzabili, indipendentemente dall'accessibilità. Questa autorizzazione consente al codice di individuare e modificare lo stato privato di un'istanza. Oltre a concedere le autorizzazioni appropriate, il tipo deve essere contrassegnato come serializzabile nei metadati.

Parametri di Type MethodInfo

Evitare di scrivere membri pubblici che utilizzano MethodInfo parametri, specialmente nel codice attendibile. Tali membri potrebbero essere più vulnerabili a codice dannoso. Si consideri, ad esempio, un membro pubblico in codice altamente attendibile che accetta un MethodInfo parametro. Si supponga che il membro pubblico chiami indirettamente il Invoke metodo sul parametro fornito. Se il membro pubblico non esegue i controlli di autorizzazione necessari, la chiamata al Invoke metodo avrà sempre esito positivo, perché il sistema di sicurezza determina che il chiamante è altamente attendibile. Anche se il codice dannoso non dispone dell'autorizzazione per richiamare direttamente il metodo, può comunque farlo indirettamente chiamando il membro pubblico.

Informazioni sulla versione

  • A partire da .NET Framework 4, il codice trasparente non può usare la reflection per accedere ai membri critici per la sicurezza.

  • Il ReflectionPermissionFlag.RestrictedMemberAccess flag è stato introdotto in .NET Framework 2.0 Service Pack 1. Le versioni precedenti di .NET Framework richiedono il flag ReflectionPermissionFlag.MemberAccess per il codice che usa reflection per accedere ai membri non pubblici. Si tratta di un'autorizzazione che non deve mai essere concessa a codice parzialmente attendibile.

  • A partire da .NET Framework 2.0, l'uso della reflection per ottenere informazioni sui tipi e sui membri non pubblici non richiede alcuna autorizzazione. Nelle versioni precedenti, è necessario usare la bandiera ReflectionPermission con ReflectionPermissionFlag.TypeInformation.

Vedere anche

  • Last updated on