I metodi Security transparent non possono contenere riferimenti a membri critici di sicurezza non pubblici

Articolo
09/12/2008

Aggiornamento: novembre 2007

TypeName	ImetodiSecuritytransparentnonpossonocontenereriferimentiamembricriticidisicurezzanonpubblici
CheckId	CA2129
Categoria	Microsoft.Security
Breaking Change	Breaking

Causa

I metodi contrassegnati con SecurityTransparentAttribute richiamano membri non pubblici, a loro volta contrassegnati con SecurityCritical. L’impostazione predefinita per i metodi è quella di SecurityTransparent.

Descrizione della regola

Con .NET Framework 2.0 è stata introdotta una funzionalità denominata trasparenza. I singoli metodi, campi, interfacce, classi e tipi possono essere o trasparenti o critici.

Il codice trasparente non ha accesso a privilegi di sicurezza avanzati. Pertanto, qualsiasi autorizzazione venga concessa o richiesta tramite tale codice viene automaticamente passata attraverso il codice al chiamante o all’AppDomain dell’ host. Esempi di privilegi avanzati sono l'accesso ad Asserzioni, LinkDemands, SuppressUnmanagedCode e codice unsafe.

Lo scopo della separazione fra codice trasparente e critico è quello di semplificare la sicurezza di controllo del processo. I controlli vengono in genere eseguiti su punti di ingresso pubblici, perché sussiste la possibilità di farne un uso dannoso e non affidabile. Contrassegnando come critiche le sezioni più piccole di un assembly, il controllo di sicurezza può essere ristretto ai punti di ingresso pubblici e alle sezioni critiche di sicurezza in grado di fornire privilegi avanzati. Ad ogni modo, per assicurarsi che il controllo sia accurato e completo, il confine tra codice trasparente e codice critico deve essere applicato nel modo più preciso possibile. L'alternativa sarebbe quella di consentire al codice trasparente di richiamare il codice critico della sicurezza interna, il quale a sua volta richiede un controllo più stretto sul codice trasparente.

In fase di Runtime, il compilatore JIT del Common Language Runtime verifica se il codice trasparente stia facendo riferimento o richiamando il codice critico della sicurezza non pubblica. Se un richiamo viene effettuato a partire da un codice trasparente verso un codice critico non pubblico, verrebbe generata un'eccezione come nell’esempio di MethodAccessException. La metodologia di gestione è in questo caso simile a quella utilizzata nel caso di una classe che tenta di accedere ai membri privati di un'altra classe.

Tale regola di analisi del codice analizza tutti i metodi e i caratteri in un assembly combinato trasparente/critico. Inoltre evidenzia qualsiasi richiamo effettuato da codice trasparente verso codice critico non pubblico che non sia contrassegnato come SecurityTreatAsSafe.

Correzione di violazioni

Per risolvere il problema, è possibile contrassegnare il codice che richiama quello SecurityCritical non pubblico come SecurityCritical; oppure contrassegnare il metodo di destinazione/carattere come SecurityTreatAsSafe. In questo modo il codice viene considerato sicuro e controllato efficacemente, in modo da essere protetto da intenti dannosi .

Soppressione degli avvisi

Non sopprimere un messaggio da questa regola.

Esempio

Il codice seguente darà un messaggio di errore perché SecondSecurityMethod è privato e SecurityCritical. Come esempio di un problema di sicurezza, l'asserzione in SecondSecurityMethod impedirà che richieste complete in azioni privilegiate e richiami esterni confluiscano in FirstSecurityMethod, limitatamente ai controlli di sicurezza eseguiti sul chiamante.

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        // SecurityTransparent
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}

Se il confine trasparente/critico non fosse applicato, FirstSecurityMethod sarebbe in grado di eseguire tutte le azioni di SecondSecurityMethod senza controlli di sicurezza.

Un'opzione consiste nella revisione del codice del metodo: se il metodo viene considerato tanto sicuro da poter accedere al livello più alto e al sicuro da attacchi, contrassegnarlo come SecurityTreatAsSafe:

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        // SecurityTransparent
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityTreatAsSafe]
        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}

Un'altra opzione consiste invece nel rendere il metodo 1 anche critico. In questo modo si espande il kernel critico dell'assembly e si aumenta la dimensione del controllo di sicurezza. In tal modo verranno garantiti un modello di minaccia e un’analisi di flusso del codice appropriati alla richiesta.

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        [System.Security.SecurityCritical]
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}